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

Start for free on Kinde.

OpenID Connect

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

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:

In Kinde, go to Settings > Applications > [Your app] > View details.
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
Select Save.

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

Signing up and signing in

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

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

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

Authorization Code Flow

Recommended for regular web applications rendered on the server.

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

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)

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

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

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

`audience`

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

Type: string

Required: No

`client_id`

The unique ID of your application in Kinde.

Type: string

Required: Yes

`code_challenge`

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

Type: string

Required: For PKCE

`code_challenge_method`

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

Type: string

Required: For PKCE

`connection_id`

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`

If an organization should be created along with the user.

Type: boolean

Required: No

`is_use_auth_success_page`

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

Type: boolean

Required: No

`has_success_page`

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`

For selecting the UI language.

Type: string

Required: No

`login_hint`

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`

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`

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)

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

Type: string

Required: No

`prompt`

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`

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

Type: string

Required: Yes

`response_type`

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

Type: string

Required: Yes

`scope`

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

Type: string

Required: No

`state`

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)

nonce

Single use code to prevent replay attacks, this will be included in the signed id token

Type: string

Required: No (but recommended)

workflow_deployment_id

workflow deployment to test, password will be requested on login

Type: string

Required: No

supports_reauth

When this is set to true, users state will be stored encrypted and returned back to application when accessing an expired link.

Type: boolean

Required: false

reauth_state

The supports_reauth is true, state will be returned with error, pass this back to the auth flow to restart flow.

Type: string

Required: No

plan_interest

Indicates which plan the user has expressed interest in to be signed up to.

Type: String

Required: No

pricing_table_key

Defines which pricing table to show in billing flow

Type: String

Required: No

Verifying the Kinde access token

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

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.

Join the community

Get support from the Kinde team and expert users in the Kinde community

Join via Slack or Discord
Contact support

Chat to support through the Kinde help widget, or send a question via email

Send an email

Using Kinde without an SDK

Get started

OpenID Connect

Set callback URLs in Kinde

Signing up and signing in

Handling successful auth for desktop and mobile apps

Handling the callback

Supported grant types for getting access tokens

Authorization Code Flow

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

Implicit flow (not supported)

OAuth 2.0 scopes

Request parameters

audience

client_id

code_challenge

code_challenge_method

connection_id

is_create_org

is_use_auth_success_page

has_success_page

lang

login_hint

org_code

org_name

start_page (deprecated)

prompt

redirect_uri

response_type

scope

state

nonce

workflow_deployment_id

supports_reauth

reauth_state

plan_interest

pricing_table_key

Verifying the Kinde access token

Signing out your users

Related articles

Kinde SDKs

About Kinde APIs

Refresh tokens

Useful links

Join the community

Contact support

`audience`

`client_id`

`code_challenge`

`code_challenge_method`

`connection_id`

`is_create_org`

`is_use_auth_success_page`

`has_success_page`

`lang`

`login_hint`

`org_code`

`org_name`

`start_page` (deprecated)

`prompt`

`redirect_uri`

`response_type`

`scope`

`state`