Skip to main content

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 sub claim.

Create the OAuth 2.0 Connection

1

Step 1: Add a Custom Connection

  1. Sign in to the ThunderID Console.
  2. Navigate to Connections.
  3. Click the Add custom connection card.
2

Step 2: Choose the Connection Type

  1. On the Connection type step, click OAuth 2.0 Provider.
  2. Click Continue.
3

Step 3: Name the Connection

  1. Enter a Connection name, or pick one of the suggested names.
  2. Click Continue.
4

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:

FieldRequiredDescription
Client IDYesThe client ID issued by the OAuth 2.0 provider.
Client secretYesThe client secret issued by the OAuth 2.0 provider.
Authorization endpointYesThe provider's authorization endpoint, used to start the sign-in flow.
Token endpointYesThe provider's token endpoint, used to exchange the authorization code for tokens.
User profile endpointNoThe 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.
note

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:

FieldDescription
ScopesSpace-separated OAuth scopes to request, beyond the provider's default.
PromptOptional 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

Explore with AI

ThunderID LogoThunderID Logo

Product

DocsAPIsSDKs
© Copyright Linux Foundation Europe.For web site terms of use, trademark policy and other project policies please see https://linuxfoundation.eu/en/policies.