Scenario - Authenticate a user when you don’t have a user ID upfront, e.g. adding a “Sign in with Google” button to your app.
Your server initiates the challenge without a userId. After the user authenticates with the provider, your server calls verify to get the provider’s identity attributes, then calls identify to associate the user with an ID in your system.
Return the authorizationUrl from the response to your client. Your client then redirects the user to this URL, which takes them to the provider’s login page.
After authenticating with the provider, the user is redirected back to your redirectUrl with challengeId and nonce query parameters. Your client should extract these values and send them to your server for verification.
If the user has previously signed in and their provider identity is already linked, the verify response will return isIdentified: true with session tokens. In this case, the user is already associated — skip the identify step and proceed with the session.
If the user is new, the response includes isIdentified: false on the user, indicating no user ID has been associated yet. The attributes object contains the verified provider data such as email, sub, emailVerified, and iss. Call identify in the next step to complete the process.
Associate the user with a user ID. You can either use the Authsignal-generated user ID from the verify response, or provide your own.Option A: Use the Authsignal-generated user IDUse the userId returned in the verify response to confirm the Authsignal-generated ID.
Scenario - Require a user to re-authenticate with a linked OAuth/OIDC provider as an additional verification step. The user must already have the provider enrolled.
Use this flow when a user is already signed in and you want to verify their identity again before a sensitive action. The provider must already be enrolled for the user — if no provider is enrolled, the challenge will return an error. If the user authenticates with a different provider account than the one linked, the verification will fail.
Scenario - Link an OAuth/OIDC provider to an existing user as an additional authentication factor. The user must be in an authenticated state.
Use this flow to let users add an OAuth/OIDC provider to their account. This requires the add:authenticators scope to be provided in the challenge call.
The add:authenticators scope is required to enrol a new OAuth/OIDC provider for an existing user. This scope should only be used when the user is in an already authenticated state. For more information on using scopes safely refer to our documentation on authenticator binding.
The OAuth/OIDC provider is now linked to the user.
If the OAuth/OIDC provider is already linked to a different user, the challenge will fail with an error.
Each provider identity (identified by the provider’s sub or equivalent identifier) can only be linked to one user at a time.