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 401 error, or in some cases a 200 response with no Sub or claims in it.

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 Is Mapped to an Attribute the Datastore Search Filter Does Not Match

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 configured through the Consent storage for OIDC Datastore Property.

Resolution 1:

Confirm that Enable User Consent Storage is set to True, and that the service account can successfully write to whichever attribute holds the consent data.

Where that attribute is configured depends on the version and the deployment, so check the right place for yours:

1. 23.07 and below - configured in the Post Auth tab.
2. 24.04 Classic realms - configured in the Datastore tab.
3. 24.04 SWAP realms - configured in the Datastore Properties.
4. Cloud - stored in the Cloud database. It is not shown or configured in the Admin Console at all, so there is nothing to check here; raise a support case if you need the stored value confirmed.

Cause 2: Sub Is Mapped to an Attribute the Datastore Search Filter Does Not Match

When an application calls the UserInfo endpoint, the endpoint takes the Sub value out of the Access Token and uses it as the User ID to look up in your Datastore. That lookup runs through the Datastore's search filter, so the filter has to match an attribute that actually holds the value Sub is carrying. If it does not, no user is found and the call returns a 401.

This applies whether or not the attribute Sub is mapped to is unique. A unique attribute such as an email address will still fail if the search filter was never told to look at it — the filter matches no user at all, rather than matching too many.

The screenshot below shows the OIDC claims table with sub mapped to Email 1.

The next screenshot shows a Datastore search filter whose only user identifier is sAMAccountName, so a Sub carrying an email address never resolves to a user.

The endpoint returns a 401 with a response body of {"error": "invalid_client"} when that lookup fails. That body is misleading: invalid_client normally points at the client credentials, but here the client is fine and the failure is the user lookup. If you see this pairing, check the Sub mapping and the search filter before spending time on the client configuration.

Resolution 2:

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 Email 1, the filter must also match the attribute holding the email address. A filter of (&(|(sAMAccountName=%v))(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) matches on sAMAccountName alone, so adding mail=%v as an OR match resolves it: (&(|(sAMAccountName=%v)(mail=%v))(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))).

The same applies to whatever attribute Sub is mapped to. Whichever it is, the search filter needs a matching (attribute=%v) clause inside the OR group, so the lookup has somewhere to find the value Sub is carrying.

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.