Authsignal SDKs can be used to implement OIDC provider authentication in the following scenarios.Documentation Index
Fetch the complete documentation index at: https://docs.authsignal.com/llms.txt
Use this file to discover all available pages before exploring further.
- Sign in or sign up. Authenticate users without a known user ID. Covers both new and returning users.
- Step-up authentication. Re-verify a known user with a linked provider before a sensitive action.
- Enrol an OIDC provider. Link a provider to an existing user as an additional authentication factor.
OIDC providers are configured per-tenant with allowed redirect URLs and per-action restrictions.
How it works
To bind the client that starts a challenge to the client that completes it, the client SDK generates acodeVerifier and a hashed codeChallenge. The codeChallenge is sent to Authsignal when the client challenge starts and the codeVerifier is persisted locally. After the user is redirected back, the SDK returns the codeVerifier alongside the authorizationToken so the server can prove the challenge is being completed by the original client.
SDK setup
Server SDK
Initialize the Server SDK using your secret key from the API keys page and the API URL for your region.Client SDK
Initialize the Client SDK with your tenant ID and the API URL for your region.Sign in or sign up
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.
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.
1. Initiate challenge
Calloidc.challenge on your server to start the OIDC provider flow. This returns an authorizationToken that your server passes back to the client.
authorizationToken from the response to your client.
2. Start the client challenge
On your client, calloidc.challenge with the authorizationToken. The SDK redirects the user to the provider’s login page.
3. Handle callback
After the user authenticates with the provider, they are redirected back to one of yourredirectUrls. Call oidc.handleCallback on your client to retrieve a short-lived authorizationToken representing the completed challenge along with the codeVerifier.
authorizationToken and codeVerifier to your server for verification.
4. Verify
On your server, callverify with the authorizationToken and codeVerifier.
Returning user
If the user has previously signed in and their provider identity is already linked, theverify 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.
New user
If the user is new, the response includesisIdentified: 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.
5. Identify
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 ID Use theuserId returned in the verify response to confirm the Authsignal-generated ID.
identify.
Step-up authentication
Scenario - Require a user to re-authenticate with a linked OIDC provider as an additional verification step. The user must already have the provider enrolled.
1. Initiate challenge
authorizationToken from the response to your client.
2. Start the client challenge
3. Handle callback
4. Verify
isIdentified: true and a session object containing accessToken and refreshToken.
Example response
Enrol an OIDC provider
Scenario - Link an OIDC provider to an existing user as an additional authentication factor. The user must be in an authenticated state.
add:authenticators scope to be provided in the challenge call.
1. Initiate challenge
Theadd:authenticators scope is required to enrol a new 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.
authorizationToken from the response to your client.

