Select authentication options
Auth and access
About Kinde authentication
Kinde makes authentication easy by providing a range of methods to choose from.
Allow your users to sign up or sign in:
- by invitation only
- using self-sign-up (default)
- with a password
- passwordless (Applied by default in all new Kinde businesses)
- with a phone number
- with a range of social sign in options, like Google, Apple, Slack, and more
- via enterprise connections such as Cloudflare or SAML
Authentication can be set per environment, and can be changed for different applications, e.g. your production web app and mobile app can have different authentication requirements.
You can start simple with email self-sign-up, and then add more options as needed, such as social sign in and multi-factor authentication.
Multi-domain authentication
Link to this sectionKinde supports:
- authenticated sessions across domains and subdomains
- users switching between domains and subdomains
Kinde supports multi-domain authentication where the primary domain is the same, but there are different subdomains. For example, website.yourdomain.com, app.yourdomain.com, docs.yourdomain.com. This is similar to how Google manages authentication for calendar.google.com, mail.google.com, etc.
Once a user is signed in to one domain or subdomain, they can switch to another and remain authenticated. To do this, you need to initiate the flow with prompt=none as part of the auth URL. This checks for a session on Kinde invisibly. If it exists the user experiences a seamless session between sites, and if a session doesn’t exist, they are prompted to reauthenticate.
See also, Manage authentication across applications.
Rate limiting if third party keys not entered
Link to this sectionWhen setting up third party authentication, such as social sign in or enterprise sign in like SAML, ensure you have added the third party Client ID and Client Secret (Keys) to the configuration screens in your live environment. If you don’t enter these details, Kinde will fallback to use our own credentials as proxy and this will cause rate limiting. This is okay for local development environments, but not for live production environments.
Get started with authentication
Link to this sectionBefore setting up authentication, think about what your audience preferences are and how you want to manage access in the short and longer term. Enabling social sign in GitHub, for example, might be expected if your audience are software developers.
Here’s a common set of tasks for getting started.