Troubleshooting: OIDC UserInfo Endpoint Returns a 401 or Fails to Return Sub and Claims

Version Affected: All
 
 

Overview

When an application calls the OpenID Connect (OIDC) UserInfo endpoint (OIDCUserInfo.aspx) to validate a user's identity information, you may see one of the following symptoms:

• See Cause 1 - the endpoint returns a 401 error.
• See Cause 2 - the endpoint returns a 200 response with no Sub or claims in it, or in some cases a 401 error instead.

Cause 1 and Cause 2 can both produce the exact same 401 error. If resolving Cause 1 does not fix the issue, check Cause 2 next.

 

In this article

• Cause 1: User Consent Storage Disabled or Not Writable
• Cause 2: Sub Claim Mapped to a Non-Unique Attribute

Cause 1: User Consent Storage Disabled or Not Writable

The User Consent Storage setting that stores information used by the UserInfo endpoint is set to False, or it is enabled but tied to an attribute the service account cannot write to.

The screenshot below shows the relevant Post Authentication settings: Enable User Consent Storage set to True, with Consent Storage Attribute set to the attribute that stores this information (Aux ID 1 in this example).

Resolution 1:

Confirm that Enable User Consent Storage is set to True, and that the service account can successfully write to whichever attribute is selected in Consent Storage Attribute.

Cause 2: Sub Claim Mapped to a Non-Unique Attribute

The UserInfo endpoint uses the Sub claim from the Access Token to look up the user in your Datastore. If Sub is mapped to anything other than the Authenticated User ID, your Datastore's search filter must also include that attribute as a match, or the lookup will not resolve to exactly one user.

Resolution 2:

To resolve this:

1. Open the Admin Console and navigate to the Post Auth tab of the OIDC realm.
2. Scroll down to the claims and check the Sub mapping.
3. Note which attribute Sub is mapped to, then switch to the Data tab for the realm's Datastore.
4. Edit the Datastore's search filter so it includes that attribute as an OR match.

For example, if Sub is mapped to AuxID1 and AuxID1 is set to Department, you would need to edit a search filter such as (&(SamAccountName=%v)(ObjectClass=*)) to (&(|(SamAccountName=%v)(Department=%v))(ObjectClass=User)).

Special Considerations

Cause 2 has also been seen to produce a 200 response with no claims in it, in addition to the 401 error described in the Overview. Both symptoms are fixed by Resolution 2.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.