About Kinde authentication
Auth and access
Here are concise answers to common authentication questions. Select a question to expand the answer.
Think about who you’re building for and what they’re used to. If you’re targeting developers, they’ll probably expect GitHub or GitLab sign-in options. Building something for everyday consumers? Google and Apple sign-in will feel familiar and remove friction. Got enterprise customers? They’ll likely need SAML or Microsoft Entra ID to keep their IT teams happy.
You don’t need to figure it all out upfront. Start simple with email authentication and add more options as you grow. Your web app and mobile app can even have different auth requirements if that makes sense for your users. Learn more about authentication methods
With passwords, your users create and remember their own passwords (we enforce 8+ characters and block common ones). With passwordless, we send them a one-time code via email or SMS instead. Passwordless is genuinely more secure - no passwords to store, steal, or forget, and codes expire after 2 hours. Just know you can’t mix both methods for the same app - it’s one or the other.
If you are building a mobile-first application or want to reduce support tickets for forgotten passwords, passwordless authentication is often a strong option. Password authentication guide | Passwordless authentication guide
Kinde automatically links accounts when a user signs in with the same verified email address across different sign-in methods. For example, if a user first signs up with Google and later signs in with Slack using the same verified email, Kinde links those identities to a single account. This prevents duplicate accounts and allows sign-in with either method.
Once your users verify their email with any method, all their sign-in options with that email will work seamlessly together. Learn about identity and verification
Yes. Configure baseline authentication methods at the environment level, then customize settings by application or organization as needed. For example, your web application might use social sign-in, your mobile app might require phone authentication, and your enterprise customers might require MFA.
This lets you align authentication requirements with each user group. Configure authentication options
Use multi-domain authentication to maintain sign-in sessions across domains and subdomains, such as website.yourapp.com, app.yourapp.com, and docs.yourapp.com. Use prompt=none in your authorization request to silently check for an existing session. If a valid session exists, users continue without interruption; otherwise, they are prompted to sign in.
About Kinde authentication
No. Kinde uses redirect-based OAuth 2.0 flows rather than inline embeddable authentication. Users are redirected to Kinde (or your custom domain) to sign in and then redirected back to your app. Embedding the auth flow in a modal or iframe is not supported. Set callback and redirect URLs
No. Programmatic login with username and password credentials via the SDK (without redirecting to Kinde’s hosted auth pages) is not supported by design for security reasons. Users must complete authentication through the redirect-based flow.
Why this design?
Kinde handles password authentication on hosted pages for security reasons. Passwords are stored as one-way hashed values and are never exposed to your application or to Kinde administrators.
Alternatives to consider:
If you need programmatic authentication (no user interaction), use the Client Credentials flow by creating a Machine-to-Machine application. Create machine-to-machine application
No. Kinde does not support the Resource Owner Password Credentials (password) OAuth grant. Use the standard redirect-based authorization code flow for user authentication. About authentication | Using Kinde without an SDK
Ask users to check their spam folder first, as email filtering is a common cause. For SMS codes, confirm network reception and phone number formatting. Verification codes expire after 2 hours, so users may need to request a new code. If you use SMS authentication, verify that your Twilio configuration is correct. Passwordless authentication troubleshooting
Before production, replace Kinde default social credentials with your own provider credentials. Default credentials are intended for testing only. Using your own credentials improves security, reliability, and operational control.
Create your own applications with each social provider (for example Google, GitHub, and Apple), then add the provider Client ID and Client Secret in Kinde social connection settings. If you use custom domains, include the correct callback URLs for those domains. Add and manage social connections
Some social providers, such as X/Twitter and Apple, may not always return an email address. Because email is required for account security and recovery flows, Kinde prompts the user for an email address during first sign-up when needed. After that step, users can continue signing in with the social provider as expected. X social sign-in | Apple social sign-in
If you are using social authentication without email/password fallback, you can streamline sign-in by routing users directly to a specific provider. Configure custom authentication pages and use the connectionId parameter to skip initial provider selection screens.
Verification and MFA screens remain managed by Kinde for security. Custom authentication pages
Generally, no - leave this off for better security. “Trusted provider” means we’ll take their word that emails are verified, but here’s the thing: people change email addresses, and social providers don’t always keep up. Only flip this switch if you’re 100% certain the provider maintains verified, current email addresses. When in doubt, err on the side of caution. Social connections configuration
SAML setup requires coordination between Kinde and the customer identity provider (IdP). Kinde acts as the service provider, while your customer provides IdP details (for example Google Workspace, Microsoft Entra ID, or Cloudflare). Create an enterprise connection in Kinde, define a unique Entity ID, and provide your ACS URL to the customer so they can complete IdP configuration.
Use certificate and private key pairs where required, and validate the flow in a sandbox environment before production rollout. Custom SAML setup
Home realm domains route users to the correct enterprise sign-in flow based on email domain. For example, when bigcorp.com is configured, users with @bigcorp.com emails are automatically directed to their company connection. Each domain can be assigned to only one connection. The SSO button is hidden by default when home realm discovery is active, but can be re-enabled if needed.
Microsoft Entra ID setup
Get your enterprise connections set up in Kinde first - SAML, Entra ID, whatever they’re using. Then when you import their user data (via CSV or JSON), we’ll automatically match everyone to the right connection based on their email addresses. This means their sign-in experience stays exactly the same - they won’t even notice you’ve switched to Kinde behind the scenes. Import their roles and permissions too if you’ve got them.
When enterprise users sign out of your application, they are signed out of Kinde but may remain signed in to their identity provider (for example Entra ID). This is expected behavior in federated authentication. If full sign-out is required across both systems, implement additional logout flows. Entra ID SAML connection
MFA requirements can be configured at different levels. You can enforce MFA globally at the environment level or apply it selectively at the organization level. For example, regulated industries may require mandatory MFA, while consumer-focused applications may choose optional MFA based on risk and UX requirements.
Kinde supports email codes, SMS codes, and authenticator apps as second factors. Just don’t use the same method twice - as in don’t make email the primary and secondary auth method. That could be confusing. Enable multi-factor authentication
Yes. You can exempt specific roles or exempt enterprise connections where MFA is already enforced by the external identity provider. Configure exemptions at the organization level. If a user has both exempt and non-exempt roles, MFA is enforced by default. Set MFA per organization
Provide clear instructions for each MFA method you support. For authenticator apps, document QR setup and remind users to store backup codes securely. For SMS, verify phone number formatting with country codes. For email codes, check spam filtering. Provide a support path for account recovery when users are locked out.
You can also reset MFA for a user. Multi-factor authentication guide
Yes. Kinde supports username authentication. It is useful for products where usernames are an important part of the user experience, such as community platforms and developer tools. Users still need to verify their email once for security, and can then sign in with their chosen username. This works with both password and passwordless methods. Username authentication guide
Usernames are treated as case-insensitive to avoid issues such as “BuilderBob” versus “builderbob” during sign-in. Users can still choose their preferred display capitalization, but matching is done without case sensitivity in the authentication process. This helps reduce sign-in friction and lowers the risk of impersonation attempts. Username authentication details
Both methods share the same password. If a user can sign in with both email and username, changing the password for one updates the credential for both. This keeps account access consistent and avoids confusion from maintaining separate passwords for the same account. Username authentication configuration
Use Device Authorization Flow for devices with limited input capability, such as smart TVs, game consoles, CLI tools, and IoT devices. The device presents a code, and the user completes authentication on a secondary device (for example a phone or laptop) with a full browser experience.
This approach reduces input friction and improves security by keeping credential entry on a trusted device. Device Authorization Flow.
The flow is: your device requests a device code from Kinde, displays a short code and verification URL, and asks the user to continue on another device. The user opens the URL, signs in with standard methods, enters the code, and authorizes the requesting device.
Meanwhile, the original device polls the token endpoint until authorization is complete and tokens are returned. Device Authorization Flow
Device Authorization Flow keeps credentials off devices that are difficult to secure. Users do not enter passwords on the TV, CLI, or IoT device; authentication occurs on a trusted browser-enabled device instead. It also preserves standard security controls such as MFA and consent prompts. Device codes are short-lived, and polling can be rate-limited to reduce abuse risk. About authentication methods
The main errors you’ll see are authorization_pending (user hasn’t finished yet - keep polling), slow_down (you’re polling too aggressively - back off), and expired_token (codes expired - start over). Handle these gracefully in your app rather than crashing. Users might also get confused about which device they’re supposed to use for what, so make your instructions crystal clear. And remember, some users will start the process but never finish it - that’s normal, just clean up expired sessions.
OAuth token validation and errors
Keep the experience simple and explicit. Display the code prominently, include the full verification URL, and provide both QR and manual entry options where possible. Use concise instructions, and include a progress state so users know the device is waiting for completion. Validate the flow with usability testing before release.
You need a paid Twilio business account because SMS delivery has carrier costs. Before setup, confirm whether 10DLC registration is required in your region and review Twilio A2P messaging requirements. Then add your Twilio configuration in Kinde, choose between a Twilio Messaging Service or a specific phone number, and set your default country. Set up phone authentication
No. Kinde uses a standardized SMS template designed to meet security and localization requirements. The message format is: “123456 is your one-time code to sign in to xxxx@login.xxx.au #123456”. The repeated code suffix is part of the security format. Phone authentication details
Use the login_hint parameter to pre-fill identity fields when the user email is known. You can also configure a unified sign-up/sign-in flow to reduce decision friction. If profile data is not required at entry, avoid collecting first and last name fields to keep onboarding minimal.
Pre-populate user identity | Manage authentication experience
Kinde can source profile pictures from identity providers such as Google and use Gravatar as a fallback when no image is available. You can disable the Gravatar fallback if you prefer to manage avatars in your own application. Some providers, such as Apple, may return limited profile data and no avatar. Authentication experience customization
Upstream parameters let you send extra data during authentication - either the same value every time (static) or something unique per user (dynamic). Common use case: passing login_hint to pre-fill sign-in forms or enabling those handy account switchers you see on Google. Each provider supports different parameters (check their docs), and you can even rename parameters using aliases if your IdP is picky about naming.
Pass parameters to identity providers
Kinde stores tokens in memory by default to reduce CSRF and XSS exposure. A browser refresh clears in-memory tokens. For production persistence, use Custom Domains to enable secure httpOnly cookies on your domain.
For local development only, is_dangerously_use_local_storage is available. Do not use this option in production.
JavaScript SDK guide | React SDK guide
Wrap your React app with KindeProvider to manage authentication state. Use hooks such as useKindeAuth() for sign-in checks, and guard rendering decisions with isLoading to avoid UI flicker. For production, use custom domains and secure cookies, and ensure redirect handlers are configured correctly.
React SDK implementation
Each framework has specific callback conventions. For example, Next.js App Router uses app/api/auth/[kindeAuth]/route.js, while Pages Router uses pages/api/auth/[...kindeAuth].js. Ensure callback URLs exactly match Kinde configuration, including protocol and case sensitivity. Prefer SDK callback handlers to reduce implementation errors.
Next.js App Router SDK | Using Kinde without SDK
Use backend SDKs or manually validate JWT tokens. SDKs reduce implementation overhead for common validation steps. The getToken() method returns bearer tokens for API calls. On the backend, validate audience and expiration claims, and never expose client secrets in frontend code.
TypeScript SDK guide
Users can hit “forgot password” on the sign-in screen and we’ll send them a one-time code via email to reset it. As an admin, you can also trigger password resets through the Kinde dashboard or API (as long as they have a verified email). There’s also the option to set a temporary password for them, but you’ll need to send it through your own channels - we won’t email passwords directly because that’s not secure. Password reset procedures
Start with the basics - did they enter their phone number correctly with the right country code? Do they have cell reception? Are they in a country where SMS might be restricted? Then check your end - is your Twilio account funded and configured properly? SMS delivery can be finicky, especially internationally, so having backup contact methods is always smart. Phone authentication setup
Start with the basics - could the email have been caught in their spam or been caught by their organization’s firewall and have been added to a supression list? Have them check this first. If you have custom SMTP email delivery set up, you should be able to check logs from the delivery provider. If you rely on Kinde to deliver emails, check the same basic things with the recipient and ask them to try again. If you need to, contact the Kinde support team to check our logs to see if there was an email disruption. Phone authentication setup
If users were relying on a social or enterprise connection that got removed or changed, they’re stuck until you fix it. Before deleting any connection, make sure nobody’s using it for auth. If you need to switch providers, set up the new one first, then help users transition by linking their accounts or setting up alternative auth methods. Always have a backup plan. Manage social connections
A common cause is URL mismatch. Callback URLs in Kinde must exactly match your application and social provider configuration, including protocol and case sensitivity. If you use custom domains, verify DNS records and active SSL certificates. Use either custom-domain tokens or Kinde-subdomain tokens consistently. Custom domain setup
Common OAuth errors include invalid_client (incorrect client credentials), invalid_grant (expired or invalid authorization code), and invalid_scope (unsupported scope). Verify credentials, exchange authorization codes promptly, and confirm scope values are valid. Return user-friendly messages instead of raw OAuth error codes.
OAuth 2.0 validation and errors
For mobile authentication, confirm deep-link configuration and URL schemes for both iOS and Android. Verify redirect URLs follow the expected custom scheme format, such as myapp://your_kinde_domain.kinde.com/kinde_callback. Use browser-based flows, because some providers (including Google) do not support webview-based authentication. If users are not receiving verification codes and Twilio is configured, review Twilio delivery logs.
React Native SDK and Set up phone auth with Twilio
For production, use custom domains to enable secure cookie storage that persists across refreshes. For local development only, you can use local storage with caution. On the backend, implement robust session management with encrypted cookies or shared cache if running multiple instances. Choose architecture-specific patterns while prioritizing security. TypeScript SDK session management
Communicate authentication trade-offs clearly. Passwordless authentication can reduce credential risk compared with passwords, MFA adds meaningful account protection, and social sign-in can be secure when configured correctly. If password authentication is enabled, recommend password managers. Kinde stores passwords as one-way hashes and cannot retrieve plain-text passwords. Password authentication security
Start with a simple baseline and add capabilities as requirements grow. Many teams begin with email authentication, then add social sign-in, MFA, and enterprise connections over time. Use organizations for multi-tenant user management. Configure common defaults at the environment level and apply organization-specific customization where needed. Implement custom domains early to simplify long-term session management. Kinde for different business models
Configure target authentication methods in Kinde first, then export and import users via CSV or JSON. If password hashes are migrated successfully, users can often continue without disruption. If authentication methods are changing (for example, to passwordless), communicate the change in advance. Validate migration steps in a sandbox environment and plan for edge cases such as password changes during the cutover window. Switch to Kinde migration guide
You can build custom sign-up and sign-in pages while Kinde continues to handle security-critical steps such as verification and MFA. Use connection IDs and login hints in authorization URLs to route users to specific authentication methods. Some screens, including password and code verification, remain hosted by Kinde for security reasons. Custom authentication pages
Use custom domains and correct cookie scoping for cross-subdomain authentication. Set cookies at the root domain so they are available across subdomains. For PHP applications, use SDK helper functions where available. Test sign-in and session continuity across all target subdomains. PHP SDK domain configuration
B2C is straightforward - configure everything at the business level with easy social sign-in and email auth. B2B gets more interesting because you’re serving multiple companies, each with their own needs. Use organizations to create separate tenant management, set up enterprise connections for business customers who need SAML or Entra ID, and keep simpler social auth for any consumer-facing parts of your platform. It’s all about matching Kinde auth options to what your customer actually needs. Business model configuration