We highly recommend using our dedicated Next.js SDK with App Router instead of this one.
Whilst technically this SDK is compatible with Next.js 13, it isn’t optimal. It leverages the use client; escape hatch, which we don’t love. It also requires a single API file to be stored in the legacy pages directory.
If you haven’t already got a Kinde account, register for free here (no credit card required). This will give you a Kinde domain, which you need to get started, e.g. yourapp.kinde.com.
Put these variables in a .env.local file in the root of your Next.js app. You can find these variables on your Kinde Settings > Applications > [Your app] > View details page.
KINDE_CLIENT_ID - Your business’s unique ID on Kinde
KINDE_CLIENT_SECRET - Your business’s secret key (do not share)
KINDE_ISSUER_URL - your kinde domain
KINDE_SITE_URL - where your app is running
KINDE_POST_LOGOUT_REDIRECT_URL - where you want users to be redirected to after logging out. Make sure this URL is under your allowed logout redirect URLs.
KINDE_POST_LOGIN_REDIRECT_URL - where you want users to be redirected to after authenticating.
Replace the information in the example below with your own information. You might also set different URLs depending where your project is running. They need to be the same as the callback URLs you entered in Kinde, above.
If you want to redirect users to a certain page after signing in, you can set the KINDE_POST_LOGIN_REDIRECT_URL environment variable in your .env.local file.
Dynamic redirect
You can also set a postLoginRedirectURL parameter to tell us where to redirect after authenticating.
This appends post_login_redirect_url to the search params when redirecting to Kinde Auth. That means you can achieve the same result as above, like this:
It’s likely that your application will have both pages that are publicly available and private ones which should only be available to logged in users. There are multiple ways you can protect pages with Kinde Auth.
On the page you want to protect, you can check if the user is authenticated and then handle it right then and there by grabbing the Kinde Auth data.
Get Kinde Auth data:
server side in getServerSideProps with the getKindeServerSession help
client side using the useKindeAuth helper
In the example above we show different content based on whether or not the user is authenticated. If you want to automatically send the user to the sign in screen, you can do something like the following:
If you want the user to be redirected back to that route after login, you can set post_login_redirect_url in the search params of the redirect.
You can also protect routes with Next.js middleware.
Default page protection
We provide a withAuth helper that will protect routes covered by the matcher. If the user is not authenticated then they are redirected to login and once they have logged in they will be redirected back to the protected page which they should now have access to.
Page protection with callback function after authorization
You can use the withAuth helper as shown below with a middleware callback function which has access to the req.kindeAuth object that exposes the token and user data.
Middleware options
There are options that can be passed into the middleware function to configure its functionality.
isReturnToCurrentPage - redirect the user back to the page they were trying to access
loginPage - define the path of the login page (where the users are redirected to when not authenticated)
publicPaths - define the public paths
isAuthorized - define the criteria for authorization
You can have your users sign in to a specific organization by setting the orgCode param in the LoginLink and RegisterLink components.
If the orgCode is not specified and the user belongs to multiple organizations, they will be prompted to choose which organization to log into during the login or register flow.
You can set the language you wish your users to see when they hit the login flow by including the lang attribute as a part of the authUrlParams when using the LoginLink and RegisterLink components.
An audience is the intended recipient of an access token - for example the API for your application. The audience argument can be passed to the Kinde client to request an audience be added to the provided token.
The audience of a token is the intended recipient of the token.
In the case you have a custom domain and you would like to start the authentication flow from a URL like auth.mysite.com and you want to redirect to a URL like app.mysite.com , all you have to do is set the KINDE_COOKIE_DOMAIN to match the domain.
If the URL you want to start the authentication flow from and the URL you want to redirect to don’t share the same domain, then this will not work.