I have setup Social Login with custom provider oauth0 but I AuthTown #ask-a-descoper

I have setup Social Login with custom provider oau...

diana sotirova

03/17/2026, 8:34 AM

I have setup Social Login with custom provider oauth0 but I am getting error:

Failed to sign up or in: [E061201] Unauthorized login attempt in oauth callback [error: [E062208] Failed to create user from mapping, external ID does not exist]

I have default mapping sub - LoginID, any help how to fix the error?

✅ 1

DevRev

03/17/2026, 8:35 AM

OAuth Mapping Configuration Issue The error indicates your OAuth provider isn't returning a valid external ID that Descope can use to create or match a user. Check Your OAuth Provider Response 1. Verify your OAuth0 provider returns the

sub

field in the user info response 2. Test the OAuth flow manually to see what data your provider actually returns

Copy code

# Test your OAuth provider's user info endpoint
curl -H "Authorization: Bearer <access_token>"  
  <https://your-oauth0-provider.com/userinfo>

Fix the Attribute Mapping 1. Go to Authentication Methods > Social Login in Descope Console 2. Edit your custom OAuth0 provider 3. In the User Attribute Mapping section: - Ensure the Login ID field is mapped to a field that exists in your provider's response - If

sub

doesn't exist, map it to another unique identifier like

id

user_id

, or

email

The error occurs because Descope can't find the external ID field you've mapped . Your OAuth provider must return the field you're mapping to Login ID in its user info response . Descope Common Errors | Descope Documentation Ethereum Wallet OAuth Provider | Descope Documentation

diana sotirova

03/17/2026, 9:00 AM

the same provider is working with sub when i setup tenant sso

DevRev

03/17/2026, 9:00 AM

Different Configuration Requirements Tenant SSO and Social Login use different authentication flows and attribute handling. Tenant SSO vs Social Login In tenant SSO, the

sub

field is processed through SAML/OIDC attribute mapping where Descope expects specific claim formats. Social Login OAuth uses a different user info endpoint and attribute structure. Debug Your OAuth Provider Response 1. Check what your OAuth0 provider actually returns in the user info response:

Copy code

# Compare the responses
# Social Login endpoint:
curl -H "Authorization: Bearer <token>" <https://your-oauth0/userinfo>
# vs your tenant SSO claims

2. In Descope Console, go to Authentication Methods > Social Login 3. Edit your OAuth0 provider and check the User Attribute Mapping 4. Map Login ID to the actual field name your provider returns (might be

id

user_id

, or

username

instead of

sub

) Common Issue Your OAuth provider likely returns different field names in the social login user info response compared to the OIDC claims used in tenant SSO . The

sub

field that works in tenant SSO might be named differently in the OAuth user info endpoint . Check your provider's documentation for the exact field names returned by their

/userinfo

endpoint versus their OIDC token claims. SSO with OIDC Provider | Descope Documentation Ethereum Wallet OAuth Provider | Descope Documentation

diana sotirova

03/17/2026, 9:01 AM

in both configurations i use the same /useinfo endpoint

DevRev

03/17/2026, 9:01 AM

Same Endpoint, Different Processing Even with the same

/userinfo

endpoint, Descope processes the response differently for Social Login vs Tenant SSO. Check the Actual Response Structure Your OAuth provider might return nested or differently formatted data. Inspect the exact JSON structure:

Copy code

curl -H "Authorization: Bearer <token>" <https://your-oauth0/userinfo> | jq .

Try Alternative Mapping In your Social Login OAuth provider configuration: 1. Go to User Attribute Mapping 2. Instead of mapping

sub

to Login ID, try: -

id

→ Login ID -

user_id

→ Login ID -

email

→ Login ID (if unique) - Or check if

sub

is nested like

user.sub

profile.sub

Enable Debug Logging The error suggests the field exists in tenant SSO but not in social login processing. This could be due to: • Different token scopes requested • Different claim processing logic • Field being present but null/empty in social login context Try mapping to

email

temporarily to see if the OAuth flow works, then identify which field contains your unique identifier in the social login response . Descope Common Errors | Descope Documentation

diana sotirova

03/17/2026, 9:24 AM

Copy code

{
  "sub": "auth0|69b8fc966f0429eccbc74dc0",
  "nickname": "user",
  "name": "User Demo",
  "picture": "<https://s.gravatar.com/avatar/c3cce426f3278113519431cae76c9310?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fus.png>",
  "updated_at": "2026-03-17T09:07:14.655Z",
  "email": "<mailto:user@demo.org|user@demo.org>",
  "email_verified": false
}

DevRev

03/17/2026, 9:24 AM

The Issue is Clear Your OAuth provider is returning the

sub

field correctly:

"sub":"auth0|69b8fc966f0429eccbc74dc0"

. Check Your Descope Mapping Configuration 1. In Descope Console, go to Authentication Methods > Social Login 2. Edit your OAuth0 provider 3. In User Attribute Mapping, verify: - Login ID field shows

sub

(not

Sub

SUB

) - No extra spaces or characters in the mapping Potential Causes The mapping looks correct, so the issue might be: 1. Case sensitivity - ensure it's exactly

sub

in lowercase 2. Special characters - the

auth0|

prefix in the sub value might be causing issues 3. Field validation - Descope might have restrictions on Login ID format Try This Mapping Instead Since your

email

field exists and is unique, temporarily map: • Login ID →

email

• Email →

email

This will help determine if the issue is with the

sub

field format or the mapping configuration itself. The

auth0|

prefix in your sub value might not be accepted as a valid Login ID format . Descope Common Errors | Descope Documentation

diana sotirova

03/17/2026, 9:29 AM

tryied with email and sub, still same error

DevRev

03/17/2026, 9:29 AM

Check Your OAuth Scopes Configuration The issue is likely missing required scopes. Your OAuth0 provider needs specific scopes to return user information. Required Scopes for Auth0 In your Descope OAuth provider configuration, ensure you have these scopes:

Copy code

openid profile email

Verify Your Configuration 1. Go to Authentication Methods > Social Login 2. Edit your OAuth0 provider 3. Check the Scopes field contains:

openid profile email

4. Verify Grant Type is set to Authorization Code Auth0 Specific Requirements Auth0 requires the

openid

scope to return the

sub

field in the userinfo response . Without it, the userinfo endpoint may not include the

sub

claim even though it appears in your test. Test the Scopes Try this curl with the scopes your Descope configuration is actually requesting:

Copy code

# Check what scopes Descope is requesting
curl -H "Authorization: Bearer <token>"  
  "<https://your-oauth0/userinfo>"  
  -v

The missing

openid

scope is the most common cause of this exact error with Auth0 providers . Custom OAuth Providers Overview | Descope Documentation

diana sotirova

03/17/2026, 9:37 AM

openid, email scopes were needed. now it works

DevRev

03/17/2026, 9:38 AM

Perfect - Scopes Fixed the Issue The

openid

scope is required for Auth0 to include the

sub

field in the userinfo response. Without it, Auth0 won't return the subject identifier that Descope needs for user mapping. Why This Happened Tenant SSO and Social Login handle scopes differently - tenant SSO uses OIDC token claims while social login relies on the OAuth userinfo endpoint, which requires explicit

openid

scope for standard claims . Your configuration is now working correctly with both

openid

and

email

scopes enabled. Custom OAuth Providers Overview | Descope Documentation

5 Views

Open in Slack

Previous Next