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
- with a password
- passwordless
- with a range of social sign in options, like Google, Apple, Slack, and more
- via enterprise auth such as Microsoft Azure AD
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.
If your authentication method requires users to sign up with an email, they will be prompted to verify their email address using a one time code. Even if they subsequently sign on using their own password, the user must verify their email the first time by entering a one time code.
If a user signs up via a social provider that does not require an email (such as Twitter or Apple), they will be prompted to enter an email address so their account can be verified.
Unlike some other authentication providers, Kinde automatically matches accounts on sign up by matching verified email addresses.
This means that if a user signs up with Google the first time, and they come back and sign up again with Slack, and the same email is detected (and we know they are both verified), then the accounts get linked. This reduces duplication and creates a better experience for users.
If your business is set up so users sign in with passwords, you can be assured that Kinde uses a hashing algorithm and never stores passwords as text. Specifically, we use Blowfish for hashing, both in transit and at rest.
When 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.
Before 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.
Authentication and access