Add an OAuth 2.0 Identity Provider
This guide explains how to register a generic OAuth 2.0 identity provider (IdP) in ThunderID. Use this type for OAuth 2.0 providers that do not implement OpenID Connect discovery. If the provider supports OIDC, use Add an OIDC Identity Provider instead.
Prerequisites
- ThunderID is running. See Get Started.
- You can sign in to the ThunderID Console.
- A client application registered in the external OAuth 2.0 provider with a Client ID and Client Secret, and permission to add the Redirect URI shown by the Console.
- The provider's authorization endpoint and token endpoint URLs, and the URL of its user profile API unless the provider issues a JWT access token carrying a
subclaim.
Create the OAuth 2.0 Connection
Step 1: Add a Custom Connection
- Sign in to the ThunderID Console.
- Navigate to Connections.
- Click the Add custom connection card.
Step 2: Choose the Connection Type
- On the Connection type step, click OAuth 2.0 Provider.
- Click Continue.
Step 3: Name the Connection
- Enter a Connection name, or pick one of the suggested names.
- Click Continue.
Step 4: Configure the Connection
The form shows a setup hint with the Redirect URI. Before creating the connection, copy it and register it as the callback URL with your provider.
Enter the following fields, then click Create connection:
| Field | Required | Description |
|---|---|---|
| Client ID | Yes | The client ID issued by the OAuth 2.0 provider. |
| Client secret | Yes | The client secret issued by the OAuth 2.0 provider. |
| Authorization endpoint | Yes | The provider's authorization endpoint, used to start the sign-in flow. |
| Token endpoint | Yes | The provider's token endpoint, used to exchange the authorization code for tokens. |
| User profile endpoint | No | The provider's own profile API, which ThunderID calls with the access token to fetch the authenticated user's attributes. It is provider-specific, for example https://api.github.com/user. |
The user profile endpoint is not an OpenID Connect UserInfo endpoint, and needs no openid scope. Provide the URL the provider documents for reading the signed-in user's profile. If your provider exposes a UserInfo endpoint, it implements OpenID Connect, so use Add an OIDC Identity Provider instead.
You can leave the field empty when the provider issues a JWT access token containing a sub claim, since ThunderID then reads the subject from that token. Sign-in fails with AUTH-OAUTH-1010 otherwise. Configure the endpoint whenever the provider offers one: the subject is the only attribute the access token supplies, so without it no email or name is available for account linking or provisioning.
After creation, open the connection. Configure the following on its edit page:
| Field | Description |
|---|---|
| Scopes | Space-separated OAuth scopes to request, beyond the provider's default. |
| Prompt | Optional prompt value forwarded to the provider's authorization request, for example select_account or consent. |
To map this provider's claims to local user attributes, go to the Attribute Configuration tab. See Attribute Configuration for the mapping concepts, which apply the same way to OAuth 2.0 connections.
Next Steps
- Connect an IdP to an Application: Add this OAuth 2.0 IdP to an application's authentication flow.
- Manage Identity Providers: Update or delete identity providers.