Kinde is designed to help founders and developers build SaaS products by providing software infrastructure like authentication, feature flags, user management, and more.

We support connecting to Kinde through our SDKs, but everything we build is also OAuth 2 standard, so you can integrate into any language framework with Kinde without an SDK.

Start for free on Kinde.

To connect to Kinde you need to know where the endpoints are for things like authorization, tokens and user profiles. You’ll also need to know the response types, scopes and claims that are supported.

All this data and more can be found in your OpenID configuration file which is located at:

https://<your_kinde_subdomain>.kinde.com/.well-known/openid-configuration

During the auth process your user will authenticate on Kinde and once authenticated will be redirected back to an endpoint in your code. To define this callback url:

1. In Kinde, go to Settings > Applications > [Your app] > View details.
2. Add your callback URLs in the relevant fields. For example:
   • Allowed callback URLs (also known as redirect URIs) - for example http://localhost:3000/api/auth/kinde_callback
   • Allowed logout redirect URLs - for example http://localhost:3000
3. Select Save.

You will need to use this redirect url in the following step.

Your users must be redirected from your product to Kinde to sign up or sign in securely. The redirect URL on your product side would look like the following:

https://<your_kinde_sudomain>.kinde.com/oauth2/auth
?response_type=code
&client_id=<your_kinde_client_id>
&redirect_uri=<your_app_redirect_url>
&scope=openid%20profile%20email
&state=abc

Note: Never include the client secret in the URL as this is publicly viewable.

Kinde supports all the standard OAuth 2 request parameters as well as a few additional Kinde-specific parameters to improve the end user experience. Full details can be found in the Request parameters table below.

Kinde also supports the PKCE extension, in which case the code_challenge and code_challenge_method parameters are also required. This is recommended for mobile apps and single page applications (SPAs).

As mentioned before when a user authenticates through Kinde, we will redirect them to the endpoint you defined in the previous step. As part of this redirect, Kinde provides an authorization code as a query parameter in the url.

Using the localhost example from before the url would look something like:

http://localhost:3000/api/auth/kinde_callback

You need to extract this authorization code parameter from the url and exchange it for an access token by making a POST request to the Kinde token endpoint https://<your_kinde_subdomain>.kinde.com/oauth/token.

As well as the code you have received, this request should also include parameters such as the client_id,  client_secret **,  redirect_uri, and grant_type (which should be set to authorization_code).

Something like this:

https://<your_kinde_sudomain>.kinde.com/oauth2/token
?client_id=<your_kinde_client_id>
&client_secret=<your_kinde_client_secret>
&grant_type=authorization_code
&redirect_uri=<your_app_redirect_url>
&code=<CALLBACK_AUTHORIZATION_CODE>

Make sure you replace the <values> with your own credentials.

This url can now be used to return the access token which can be stored and later used to make authenticated requests on behalf of the user.

Note that the code_verifier is also required in PKCE flow. The response body will then contain a token that you can decode.

Do not include the client secret in frontend / single page applications as this is publicly viewable - instead use the PKCE extension.

Recommended for regular web applications rendered on the server.

Kinde supports the PKCE extension, in which case the code_challenge and code_challenge_method parameters are also required. This is recommended for mobile apps and single page applications (SPAs).

Before PKCE (see above) this was the method used by applications that were unable to store secrets securely. This flow has security implications and Kinde does not support it for this reason.

The following scopes can be requested from Kinde.

openid - requests an ID token which contains information about the user

email - requests a user’s email

profile - requests profile details as part of ID token, e.g. name, family name, given name, picture (avatar)

offline - request to act on behalf of the user even if they’re offline

There are a few useful additional parameters that Kinde supports in the authorization URL.

The audience claim for the JWT. This can be used to protect your APIs and resource servers.

Type: string

Required: No

The unique ID of your application in Kinde.

Type: string

Required: Yes

A base64 encoded string of a SHA256 hash of a code verifier.

Type: string

Required: For PKCE

Should always be S256 tells Kinde the method used to hash the code challenge above

Type: string

Required: For PKCE

Connection ID for authentication method when using Custom sign-up and sign-in pages

Type: string

Required: When using custom sign up and sign in pages

If an organization should be created along with the user.

Type: boolean

Required: No

For selecting the UI language.

Type: string

Required: No

When your project knows which user it is trying to authenticate, it can provide their email  in this parameter as a hint to Kinde. Passing this hint pre-fills the email box on the sign up and sign-in screens.

Type: string

Required: No

For multi-tenant or platform apps, tell Kinde which organization a user is trying to sign in or sign up to.

Type: string

Required: No

If is_create_org is passed then you can optionally include the name of the organization your would like to create.

Type: string

Required: No

Accepts login or registration, but we recommend using prompt as per below instead.

Type: string

Required: No

Accepts login or create so you can determine if your user should land on the sign up or sign in page. By default users will land on the sign in page. You can also use none.

If you use none Kinde will not show authentication screens to the user.

• If the user has an active SSO session, this will redirect them to the callback URL where the token exchange can occur.

• If the user does NOT have an active SSO session, this will redirect them to the callback URL with the following error:

  302 https://YOUR_CALLBACK_URL?
  error=login_required&
  error_description=User+authentication+is+required&
  state=YOUR_STATE

Type: string

Required: No

The URL that the user will be returned to after authentication.

Type: string

Required: Yes

Should always be code. Kinde does not support the implicit flow as it has shown to be unsecure.

Type: string

Required: Yes

The scopes to be requested from Kinde. Scopes include openid, profile, email, offline.

Type: string

Required: No

Kinde will return this to your app so you can validate it came from us and prevent CSRF attacks.

Type: string

Required: No (but recommended)

It’s likely you will be using a library to validate your JWTs and they will require the url for your public JSON Web Key (also known as a jwks file).

The file can be found here:

https://<your_kinde_subdomain>.kinde.com/.well-known/jwks

When user sign out, you will want to clear any session or locally stored data in your app and redirect them to your preferred logout URL with the redirect parameter. Such as:

https://<your_kinde_subdomain>.kinde.com/logout?redirect=<your_logout_url>

This will end their session on Kinde. A new access token or refresh token needs to be issued for them to sign in again.

To add a logout URL in Kinde, go to Settings > Applications > View Details, then add the URLs to the Allowed logout redirect URLs field. Users will be redirected back to this URL when they sign out.