React-admin front-end and Next edge-runtime back-end - which SDKs/applications and how to auth API?
Hi,
I'm using react-admin and have successfully implemented the front-end auth flow with Kinde and React SDK. I'm now trying to authenticate back-end API access in Next JS (Vercel) edge-runtime from the front-end using the Next JS SDK but for some reason it's not authenticating:
- I already have a front-end React Kinde application for the login journey and a back-end Next JS Kinde application for the API journey
- Despite the front-end login flow working, the front-end auth token is rejected by the Kinde back-end SDK as follows (no middleware yet):
//authenticated front-end client calling back-end api
import { useKindeAuth } from '@kinde-oss/kinde-auth-react'
const auth = useKindeAuth()
if (auth.isAuthenticated) {
const res = await fetch(/api/auth, {
headers: {
Authorization: Bearer ${await auth.getToken()},
},
})
} // all works fine
//back-end api in app/api/auth/route.js (will eventually move to middleware)
import { SignJWT, createRemoteJWKSet, jwtVerify } from 'jose'
import { getKindeServerSession } from '@kinde-oss/kinde-auth-nextjs/server'
export async function GET(request: Request) {
//test validity of front-end JWT
const fetoken = getJwt(request)
const JWKS = createRemoteJWKSet(new URL('https://<my-kinde-name>/.well-known/jwks'))
const result = await jwtVerify(fetoken, JWKS, {
issuer: 'https://<my-kinde-name>.kinde.com',
requiredClaims: ['sub', 'email', 'org_code', 'permissions'],
}) // this successfully decodes and verifies the JWT
//*HOWEVER*
const { getAccessToken, isAuthenticated } = getKindeServerSession()
console.log(await getAccessToken()) // this logs "Invalid token specified" on the server
const isAuth = await isAuthenticated() //this returns false
<snip>
}
How do I load the Kinde Next JS session (or router/client, etc.) from the JWT in order to take advantage of the SDK convenience methods to access the claims?
Many thanks,
James8 Replies
Hey James,
The getKindeServerSession() method is designed to work with the Kinde session directly and might not be the best approach for verifying a token sent from the front-end. This method is typically used in scenarios where the session is established through the Kinde authentication flow directly in the Next.js application, rather than verifying a token from a different context (like a front-end application).
Given your setup, where you have a separate front-end application handling authentication and then sending a token to a Next.js back-end, you might need to manually verify the token using a method similar to your current approach with the jwtVerify function from the jose library. This is because the getKindeServerSession() method expects to work within the context of a session established by the Kinde Next.js SDK, which might not be present in your case.
For accessing the claims and performing operations based on the authenticated user, you would continue using the decoded token result from the jwtVerify function. If you need to perform actions that require Kinde SDK methods (like getting user information or permissions), you might need to directly call the Kinde Management API with the necessary credentials, as the SDK convenience methods rely on the session context.
If you're looking to integrate Kinde authentication more seamlessly between your front-end and back-end, ensuring that the session is shared or accessible in both contexts is crucial. This might involve setting up your Next.js application to handle the authentication flow directly or finding a way to securely transfer the session context from the front-end to the back-end.
Also not sure if you have seen this, which also help - https://kinde.com/docs/developer-tools/kinde-edge-workers/
Kinde Docs
Kinde and edge worker services - Developer tools - Help center
Our developer tools provide everything you need to get started with Kinde.
Thanks @Andre @ Kinde - I've gone ahead and rolled my own Next middleware that verifies & decodes the front-end Kinde token as you suggest and all is working well.
Two open questions I still have from your docs though
- If I also implement your Flutter SDK for a mobile app, should I create another Kinde application for that or should I re-use the same one as my React front-end?
- Is the M2M auth flow only applicable to accessing your Kinde management API or can it also be used to manage access to my own APIs? My understanding is that it's just the former, but I just wanted to double check!
Thanks again
Hey James
Yay! Awesome to hear it worked for you.
1. If you are using Flutter for the Front end, you could reuse the React application in your account. But having it as a different application will allow you to change token lifetimes etc
2. The M2M (Machine to Machine) auth flow in Kinde is primarily designed for securing access to the Kinde Management API, allowing your systems to interact with Kinde's functionalities programmatically. However, Kinde also supports the integration of your own APIs by registering them with Kinde. This means you can secure access to your own APIs using Kinde's authentication mechanisms, ensuring that access requests to your endpoints are secure and authorized. https://kinde.com/docs/build/register-an-api/#register-and-manage-apis
Kinde Docs
Register and manage APIs - Build on Kinde - Help center
Our developer tools provide everything you need to get started with Kinde.
Let me know if this has helped
Thanks @Andre @ Kinde - I'm already using using the audience claim between my front-end and back-end. But I was more referring to the authentication of 3rd party M2M consumers of my APIs - am I correct assuming that Kinde doesn't currently support this use case (as there's only à single Client ID & secret provided)? If so, support for managing additional 3rd party M2M creds (oauth or api key) would be an awesome addition! Is it on the roadmap?
Ohhh got it. So your use case is more about assigning a M2M token to a user with a certain audience/scope?
Yes, as well as a React front-end, there are also direct consumers of my REST APIs, so they each need to authenticateb to get an audience/scope too. I've implemented support for an x-api-key auth in my Nezt middleware that creates a JWT, but it occurred to me that this is something that Kinde could support as an extension of the M2M model, as you have almost all the pièces to offer a more secure oauth version with audience permissions, etc.
Awesome, thanks for explaining this. We do get regular requests for this feature every other week, and the team is looking at beginning work on it in the next month or so.