Use 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 follows the OAuth 2.0 standard, so you can integrate Kinde into any language or framework without an SDK.

What you need

A Kinde account with Admin or Engineer access (Sign up for free)
Knowledge of programming languages and OAuth 2.0

Quickstart

1. Create a Kinde application

Sign in to your Kinde dashboard and select Add application
Enter a name for the application (e.g., “My App”)
Select an application type:
- Back-end web: for server-rendered or full-stack apps
- Front-end and mobile: for JavaScript-based single-page applications (SPAs) or mobile apps
Select Other
Select Save.

2. Get your app keys

In your app settings page, select Details
Copy your app keys:
- Custom domain: if you have configured a custom domain
- Domain: your Kinde domain (use it if you don’t have a custom domain)
- Client ID: a unique identifier for your app
- Client secret: (only for back-end apps)
You will need these keys to connect your codebase with Kinde.

3. Add a callback URL

In your app’s Details page, scroll down to the Callback URLs section
Add the following URLs:
- Allowed callback URLs (e.g., http://localhost:3000/auth/callback)
- Allowed logout redirect URLs (e.g., http://localhost:3000)
You can add more than one callback URL per line.

About callback URLs

Authorization servers require the callback URL to be registered ahead of time to prevent abuse. Whatever path you use for your callback URL, it must be registered with Kinde. The logout redirect URL is where Kinde redirects users after they sign out — typically your app’s homepage.
Select Save

4. Set authentication methods

In your app’s settings page, go to Authentication
Enable the authentication methods you want your users to sign in with (e.g., Google, Apple, SSO, etc.)
Select Save

5. Get the OpenID endpoints

These are the OpenID endpoints for Kinde, found at:

<YOUR_DOMAIN>/.well-known/openid-configuration

Authorization endpoint: <YOUR_DOMAIN>/oauth2/auth
Token endpoint: <YOUR_DOMAIN>/oauth2/token
Userinfo endpoint: <YOUR_DOMAIN>/oauth2/v2/user_profile
Logout endpoint: <YOUR_DOMAIN>/logout

Other endpoints:

JWKS URI: <YOUR_DOMAIN>/.well-known/jwks
Revocation endpoint: <YOUR_DOMAIN>/oauth2/revoke
Introspection endpoint: <YOUR_DOMAIN>/oauth2/introspect

6. Create the authorization request

Your user clicks a button to sign in or sign up in your app.

Backend application
SPAs and mobile apps

In your app, generate a random state value and a nonce:
Node.js example
```
import crypto from 'node:crypto';

const state = crypto.randomBytes(32).toString('hex');
const nonce = crypto.randomBytes(32).toString('hex');
```
Store state and nonce in your server-side session — you will need them when the user returns to the callback URL.

Send the user to Kinde’s authorization endpoint with the state and nonce parameters included in the URL:

GET <YOUR_DOMAIN>/oauth2/auth
?response_type=code
&client_id=<your_kinde_client_id>
&redirect_uri=<your_app_redirect_url>
&scope=openid%20profile%20email
&state=<your_random_state_value_min_8_characters>
&nonce=<your_random_nonce_value>

In your app, generate a random state value, a nonce, a code_verifier, and derive a code_challenge from it:

function base64UrlEncode(buffer) {
  const bytes = new Uint8Array(buffer);
  let binary = '';
  for (const byte of bytes) {
    binary += String.fromCharCode(byte);
  }
  return btoa(binary)
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '');
}

const stateBytes = new Uint8Array(32);
crypto.getRandomValues(stateBytes);
const state = Array.from(stateBytes, (b) =>
  b.toString(16).padStart(2, '0')
).join('');

const nonceBytes = new Uint8Array(32);
crypto.getRandomValues(nonceBytes);
const nonce = Array.from(nonceBytes, (b) =>
  b.toString(16).padStart(2, '0')
).join('');

// 64 random bytes, base64url-encoded = 86-char code_verifier
const verifierBytes = new Uint8Array(64);
crypto.getRandomValues(verifierBytes);
const codeVerifier = base64UrlEncode(verifierBytes);

// SHA-256 hash of the verifier, base64url-encoded = code_challenge
const digest = await crypto.subtle.digest(
  'SHA-256',
  new TextEncoder().encode(codeVerifier)
);
const codeChallenge = base64UrlEncode(digest);

Store state, nonce, and code_verifier in sessionStorage (for SPAs) and secure device storage (Keychain/Keystore) for mobile apps— you will need them when the user returns to the callback URL.

Send the user to Kinde’s authorization endpoint with the state, nonce, and PKCE parameters included in the URL:

GET <YOUR_DOMAIN>/oauth2/auth
?response_type=code
&client_id=<your_kinde_client_id>
&redirect_uri=<your_app_redirect_url>
&scope=openid%20profile%20email
&state=<your_random_state_value_min_8_characters>
&nonce=<your_random_nonce_value>
&code_challenge=<code_challenge>
&code_challenge_method=S256

The user is redirected to the Kinde sign in page and authenticates with their credentials (email/password, social login, SSO, etc.).

7. Handle the callback

Kinde redirects the user back to your redirect_uri with an authorization code and the original state value as query parameters:
```
https://your-app.com/auth/callback
?code=<AUTHORIZATION_CODE>
&state=<your_random_state_value_min_8_characters>
```
Validate that the returned state matches the one you generated in the previous step to prevent CSRF attacks.

Backend application
SPAs and mobile apps

Exchange the authorization code for tokens by making a POST request to the Kinde token endpoint:

POST <YOUR_DOMAIN>/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=<AUTHORIZATION_CODE>
&redirect_uri=<your_app_redirect_url>
&client_id=<your_kinde_client_id>
&client_secret=<your_kinde_client_secret>

Exchange the authorization code for tokens by making a POST request to the Kinde token endpoint with the code_verifier — no client_secret needed:

POST <YOUR_DOMAIN>/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=<AUTHORIZATION_CODE>
&redirect_uri=<your_app_redirect_url>
&client_id=<your_kinde_client_id>
&code_verifier=<code_verifier>

Kinde returns the tokens in the response body (same for both flows):

{
  "access_token": "...",
  "id_token": "...",
  "refresh_token": "..." // only if the "offline" scope was requested
}

8. Display user information

Redirect the user to a protected page in your app
Decode the id_token with any standard JWT library, or if you are using JavaScript, use the Kinde JavaScript library. Validate that the nonce claim matches the value you stored earlier to prevent replay attacks.

Use the decoded claims to display in your app:

{
  "sub": "kp_7a4b2c...",
  "given_name": "Jane",
  "family_name": "Doe",
  "email": "jane@example.com",
  "picture": "https://gravatar.com/...",
  "nonce": "<your_random_nonce_value>",
  "iat": 1716800000,
  "exp": 1716886400
}

Alternatively, you can call the userinfo endpoint, passing the access_token as a Bearer token. This always returns an up-to-date version of the user’s profile. See When should I use the userinfo endpoint instead of decoding the id_token? for more details.

9. Test user registration

Complete the registration flow in your app and verify that you can sign in to a protected page (e.g., a dashboard).

Go to your Kinde dashboard and select Users
You should see the new user’s details in the list.

Authentication

The following link redirects the user to the Kinde sign-in page by default:

GET <YOUR_DOMAIN>/oauth2/auth
?response_type=code
&client_id=<your_kinde_client_id>
&redirect_uri=<your_app_redirect_url>
&scope=openid%20profile%20email
&state=<your_random_state_value_min_8_characters>
&nonce=<your_random_nonce_value>

To send the user to the sign-up page instead, add prompt=create to the URL:

GET <YOUR_DOMAIN>/oauth2/auth
?response_type=code
&client_id=<your_kinde_client_id>
&redirect_uri=<your_app_redirect_url>
&scope=openid%20profile%20email
&state=<your_random_state_value_min_8_characters>
&nonce=<your_random_nonce_value>
&prompt=create

Handle successful auth for desktop and mobile apps

If you offer mobile and desktop apps alongside a browser-based version, 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 has_success_page parameter to the authorization URL.

Protect a route with auth

Route protection works at two layers. Both are required — the frontend layer is UX, the backend layer is the real security gate.

Layer 1: Frontend — redirect unauthenticated users

Before rendering a protected page or screen, check that you have a valid, non-expired access token. If not, redirect to the Kinde authorization endpoint:

function isTokenExpired(token) {
  // JWT payloads are base64url-encoded; convert to standard base64 before decoding
  const base64Url = token.split('.')[1];
  const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  const { exp } = JSON.parse(atob(base64));
  return Date.now() >= exp * 1000;
}

// Run this check on every protected page load
if (!accessToken || isTokenExpired(accessToken)) {
  window.location.href =
    '<YOUR_DOMAIN>/oauth2/auth?response_type=code&client_id=<CLIENT_ID>&...';
}

Layer 2: Backend — verify the token on every request

Your server must validate the access token on every call to a protected endpoint. Send the token in the Authorization header:

GET /api/protected-resource
Authorization: Bearer <access_token>

On the server, verify the token before returning any data:

// Pseudocode — pattern is the same in Node, Python, Go, etc.
function protectedRoute(req, res, next) {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) return res.status(401).json({ error: 'Unauthorized' });

  try {
    const payload = verifyJWT(token, {
      jwksUri: '<YOUR_DOMAIN>/.well-known/jwks',
      issuer: '<YOUR_DOMAIN>',
    });
    req.user = payload; // access sub, org_code, scp, permissions
    next();
  } catch {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
}

See Validate the access token below for the full list of claims to check.

Using claims for authorization

Once the token is verified, use the claims inside it to make access decisions:

Claim	Use for
`sub`	Identify the user — link to your own database records
`scp`	Check the user has the required OAuth scopes
`permissions`	Fine-grained access control (e.g. `read:reports`)
`org_code`	Multi-tenant apps — confirm the user belongs to the right organization

Handling token expiry

By default, access tokens expire after 24 hours. If you requested the offline scope, use the refresh token to get a new access token silently — without sending the user through the login flow again:

Backend application
SPAs and mobile apps

POST <YOUR_DOMAIN>/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=<CLIENT_ID>
&client_secret=<CLIENT_SECRET>
&refresh_token=<REFRESH_TOKEN>

POST <YOUR_DOMAIN>/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=<CLIENT_ID>
&refresh_token=<REFRESH_TOKEN>

If no refresh token is available (i.e. offline scope was not requested), redirect the user to sign in again.

Validate the access token

Always verify the access_token signature on your server before trusting any request. Kinde signs tokens with RS256 and publishes its public keys at the JWKS endpoint:

<YOUR_DOMAIN>/.well-known/jwks

Most JWT libraries accept a JWKS URL directly — point your library at this URL and it will fetch and cache the correct public key automatically.

As part of verification, validate the following claims:

Claim	Expected value
`iss`	`<YOUR_DOMAIN>`
`aud`	Your API audience if configured
`exp`	Must be in the future
`iat`	Must be in the past

Reject any token that fails signature verification or has an unexpected claim value.

Kinde self-serve portal link

Call the Kinde Account API with the logged-in user’s access token to generate a self-serve portal link for the user:

const response = await fetch("<YOUR_DOMAIN>/account_api/v1/portal_link", {
  headers: {
    Authorization: `Bearer ${userAccessToken}`
  }
});
const data = await response.json();
window.location = data.url;

Optional parameters:

subnav – specify the portal section to open (e.g., organization_details, profile).
return_url – where to redirect the user after exiting the portal.

See: Self-serve portal for users.

Sign out your users

To sign a user out:

Clear any session or token storage in your app
Redirect them to the Kinde logout endpoint with your logout URL:
```
<YOUR_DOMAIN>/logout?redirect=<your_logout_url>
```
This ends their Kinde session. They will need to authenticate again to receive new tokens.

To register a logout URL, go to Settings > Applications > [Your app] > View details, then add it to the Allowed logout redirect URLs field.

Supported grant types in Kinde

Authorization Code Flow

The Authorization Code Flow is the standard way to sign users in when your app runs on a server you control. Instead of returning tokens directly in the browser, Kinde redirects the user back to your app with a short-lived authorization code. Your server then exchanges that code for tokens by making a secure back-channel request to Kinde’s token endpoint, including your client_secret. This two-step design keeps tokens off the URL and out of the browser — the authorization code is useless on its own without your secret. Use this flow for server-rendered web applications, traditional back-end web apps, and any client that can store a client_secret securely on the server.

PKCE extension

The Authorization Code Flow with PKCE (Proof Key for Code Exchange) works the same way, but replaces the client_secret with a one-time cryptographic proof. Before redirecting the user to Kinde, your app generates a random code_verifier and sends a hashed version (code_challenge) in the authorization request. When exchanging the authorization code for tokens, your app sends the original code_verifier instead of a secret. Kinde verifies they match, proving that the same app that started the login is completing it. This matters because single-page apps (SPAs) and mobile apps are “public clients” — their code runs on the user’s device, so a client_secret could be extracted and abused. PKCE gives you the security of the authorization code flow without needing a secret. Use PKCE for SPAs, native mobile apps, desktop apps, and any client that cannot keep a client_secret confidential.

Implicit flow (Not recommended)

The Implicit Flow was originally created for browser-based apps that couldn’t keep a secret — it returned the access_token directly in the URL fragment after login. That convenience came at a serious cost: tokens in URL fragments can leak through browser history, referrer headers, and server logs. The OAuth 2.0 Security Best Current Practice (RFC 9700) now explicitly recommends against using the Implicit Flow for any new application.

What to use instead: The Authorization Code Flow with PKCE is the correct choice for all public clients — including single-page apps and mobile apps — regardless of whether they can store a client secret. PKCE (Proof Key for Code Exchange) solves the same problem the Implicit Flow was trying to address, without the token-in-URL security exposure.

If you are migrating an existing app from the Implicit Flow, replace the flow type token with code and add the code_challenge and code_challenge_method parameters to your authorization request. No client secret is required.

OAuth 2.0 scopes for Kinde

The following scopes can be requested from Kinde.

`openid`

Requests an id_token that contains information about the authenticated user.

`email`

Requests the email and email_verified claims in the id_token.

`profile`

Requests profile details as part of the id_token, including given name, family name, and picture.

`offline`

Requests a refresh_token that can be used to silently refresh the access_token when it expires.

`phone`

Requests the phone_number and phone_number_verified claims in the id_token.

`address`

Requests the address claim in the id_token.

Request parameters

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

`response_type`

Should always be code. Kinde does not support the Implicit Flow — see Does Kinde support the Implicit Flow? for details.

Type: string

Required: Yes

`client_id`

The unique ID of your application in Kinde.

Type: string

Required: Yes

A single-use value included in the signed id_token to prevent replay attacks.

Type: string

Required: No (but recommended)

`code_challenge`

A base64url-encoded SHA-256 hash of the code verifier.

Type: string

Required: for public clients (e.g., SPAs and mobile apps)

`code_challenge_method`

Should always be S256. This tells Kinde that the code challenge was generated using SHA-256.

Type: string

Required: For PKCE

`prompt`

Accepts login, create, consent, select_account, or none to control which page users land on. By default, users are directed to the sign-in page.

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 <YOUR_CALLBACK_URL>?
error=login_required&
error_description=User+authentication+is+required&
state=YOUR_STATE
```

Decoding the id_token is usually the fastest approach — it requires no extra network request. However, there are three situations where calling the userinfo endpoint is the right choice:

You need up-to-date profile data. The id_token is a snapshot frozen at login time. If the user updates their name, email, or avatar in Kinde after they’ve authenticated, the id_token stays stale until they get a new one. The userinfo endpoint queries Kinde live and always returns current data.
Your backend only has the access_token. The id_token is typically held by the frontend. If your server needs to look up the authenticated user’s profile, it can call the userinfo endpoint using the access_token from the request header — without needing the frontend to forward the id_token separately.
You didn’t request the openid scope. Without openid, no id_token is issued. The userinfo endpoint still works as long as you hold a valid access_token.

In all other cases, prefer decoding the id_token — it’s faster and requires no round trip to Kinde.

To call the userinfo endpoint, pass the access_token as a Bearer token:

GET https://<YOUR_DOMAIN>/oauth2/v2/user_profile
Authorization: Bearer <access_token>

The response returns the user’s current profile fields:

{
  "sub": "kp_7a4b2c...",
  "given_name": "Jane",
  "family_name": "Doe",
  "email": "jane@example.com",
  "picture": "https://gravatar.com/..."
}

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

Use Kinde without an SDK

What you need

Quickstart

1. Create a Kinde application

2. Get your app keys

3. Add a callback URL

4. Set authentication methods

5. Get the OpenID endpoints

6. Create the authorization request

7. Handle the callback

8. Display user information

9. Test user registration

Authentication

Create a sign in or sign up link

Handle successful auth for desktop and mobile apps

Protect a route with auth

Validate the access token

Kinde self-serve portal link

Sign out your users

Supported grant types in Kinde

Authorization Code Flow

PKCE extension

Implicit flow (Not recommended)

OAuth 2.0 scopes for Kinde

openid

email

profile

offline

phone

address

Request parameters

response_type

client_id

redirect_uri

scope

state

nonce

code_challenge

code_challenge_method

prompt

login_hint

org_code

is_create_org

org_name

audience

has_success_page

lang

connection_id

supports_reauth

reauth_state

deploy_id

plan_interest

pricing_table_key

start_page (deprecated)

FAQs

When should I use the userinfo endpoint instead of decoding the id_token?

Related articles

Kinde SDKs

About Kinde APIs

Refresh tokens

Useful links

Join the community

Contact support

`openid`

`email`

`profile`

`offline`

`phone`

`address`

`response_type`

`client_id`

`redirect_uri`

`scope`

`state`

`nonce`

`code_challenge`

`code_challenge_method`

`prompt`

`login_hint`

`org_code`

`is_create_org`

`org_name`

`audience`

`has_success_page`

`lang`

`connection_id`

`supports_reauth`

`reauth_state`

`deploy_id`

`plan_interest`

`pricing_table_key`

`start_page` (deprecated)

When should I use the userinfo endpoint instead of decoding the `id_token`?