Using Kinde without an SDK

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.

Get started

Link to this section

Start for free on Kinde.

OpenID Connect

Link to this section

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

Set callback URLs in Kinde

Link to this section

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.

Signing up and signing in

Link to this section

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).

Handling successful auth for desktop and mobile apps

Link to this section

If you offer mobile and desktop apps, as well as access through a browser, you’ll need to handle the post-authentication browser state. Rather than leaving a hanging screen, you can show users a success page. To do this, add the is_use_auth_success_page parameter to the authorization URL. See the Request prameters section below.

Handling the callback

Link to this section

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/oauth2/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).

Make a POST request with the following payload:

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.

Supported grant types for getting access tokens

Link to this section

Authorization Code Flow

Link to this section

Recommended for regular web applications rendered on the server.

Authorization Code Flow with Proof Key for Code Exchange (PKCE)

Link to this section

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).

Implicit flow (not supported)

Link to this section

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.

OAuth 2.0 scopes

Link to this section

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

Request parameters

Link to this section

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

audience

Link to this section

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

Type: string

Required: No

client_id

Link to this section

The unique ID of your application in Kinde.

Type: string

Required: Yes

code_challenge

Link to this section

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

Type: string

Required: For PKCE

code_challenge_method

Link to this section

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

Type: string

Required: For PKCE

connection_id

Link to this section

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

is_create_org

Link to this section

If an organization should be created along with the user.

Type: boolean

Required: No

is_use_auth_success_page

Link to this section

Displays a sign-in success page following authentication. Recommended for browser authentication.

Type: boolean

Required: No

has_success_page

Link to this section

Show a success page at the end of the auth flow, this is useful when the callback URL is not a web page

Type: boolean

Required: No

lang

Link to this section

For selecting the UI language.

Type: string

Required: No

login_hint

Link to this section

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

org_code

Link to this section

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

org_name

Link to this section

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

Type: string

Required: No

start_page (deprecated)

Link to this section

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

Type: string

Required: No

prompt

Link to this section

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

redirect_uri

Link to this section

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

Type: string

Required: Yes

response_type

Link to this section

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

Type: string

Required: Yes

scope

Link to this section

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

Type: string

Required: No

state

Link to this section

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)

Verifying the Kinde access token

Link to this section

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

Signing out your users

Link to this section

When users 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.