OAuth / OIDC – Access Token and ID Token Identical, "/userinfo" Fails with JWT

Customer IAM (CIAM) SSO
1

Hi,

During our OAuth 2.0 / OpenID Connect integration with OpenIAM(Autorization server and OIDC identity provider), we expirience the following issues:

Issue 1 :

When executing a successful Authorization Code or PKCE flow, OpenIAM returns both an id_token and an access_token also refresh_token when is set to on; however, both tokens id_token and an access_token are identical (same JWT).

The token payload contains claims such as:

  • nonce

  • at_hash

  • c_hash

  • auth_time

These claims are ID Token specific according to the OIDC specification and should not appear in an Access Token. The acces_token should be something similar to this:

{

“iss”: “http://xxxxxxxxxxx/idp/oauth2/OAUTHOICD-SSO”,

“sub”: “8a8a8fff9c9f37c7019d069ef9440409”,

“aud”: “userinfo”,

“scope”: “openid profile email”,

“exp”: 1776327142,

“iat”: 1776325342

}..

..

ID Tokens and Access Tokens must be diferent and serve separete purposes .

Issue 2:

when “Send JWT Token as Access Token” is enabled,id_token and access_token are byte-for-byte identical, and /userinfo OpenIAM endpoint responds with:

{

“error”: “invalid_request”,

“error_description”: “Provided token is not found”

}

/userinfo strictly requires a valid Access Token, when we use am opake token works properly.

Questions

  1. Is it expected behavior that enabling “Send JWT Token as Access Token” results in the same JWT being used as both id_token and access_token?

  2. If not, what is the correct configuration to ensure separate token issuance in compliance with OAuth 2.0 / OIDC?

  3. Is there anything else i should do for using /userinfo endpoint.

  4. I follow links from OpenIAM setup, ¿is there any other source i should follow for solving these?: OpenID Connect (OIDC),oAuth 2.0,OpenIAM oAuth2.0 Scopes

We appreciate your guidance to resolve this issues, my current OpenIAM Version: 4.2.1.15.1702.

Kind regards,

Mauro

2

Hello @mlmoreno,

Q1: Is it expected behavior that enabling “Send JWT Token as Access Token” results in the same JWT being used as both id_token and access_token?

Yes, this is the current behavior when “Send JWT Token as Access Token” is enabled. When this option is turned on, OpenIAM sends the same JWT as both the access_token and

id_token as a convenience for clients that require a JWT-format access token.

Q2: What is the correct configuration to ensure separate token issuance in compliance with OAuth 2.0 / OIDC?

For a fully OIDC-compliant setup with distinct id_token and access_token, use the following configuration:

  • Set “Send JWT Token as Access Token” → Off

With this setting disabled, OpenIAM issues:

  • An opaque access_token — used to authorize calls to protected endpoints including /userinfo

  • A JWT id_token — used on your client to verify the user’s identity, containing OIDC-specific claims such as nonce, auth_time, at_hash, and profile information

This is the recommended and fully supported configuration for OIDC compliance. Your client application should use the id_token for identity verification, and pass the opaque

access_token as a Bearer token when calling APIs or /userinfo.

Q3: Is there anything else I should do to use the /userinfo endpoint correctly?

Yes, please verify the following checklist:

1. “Send JWT Token as Access Token” must be Off (as described above)

2. Call /userinfo using the opaque access_token as the Bearer token:

GET /idp/oauth2/userinfo

Authorization: Bearer <access_token>

3. Ensure the user has the correct entitlements to the OAuth Authentication Provider via a Role or Group assignment

4. Verify the “Is OAuth client Authorization Disabled” checkbox under Administration > System Configuration > System tab:

- If this is unchecked and the user lacks entitlements to the provider, the request will fail with insufficient_rights

5. Confirm the scopes configured on your provider include the claims you expect back (e.g., openid, profile, email)

6. Validate your provider’s supported scopes and endpoints anytime via the OpenID Connect Discovery URL (well-known URI) available on your Authentication Provider configuration page in the webconsole

Following the configuration above on OpenIAM version 4.2.1.15, /userinfo will respond correctly with the expected user profile claims.

Hope this helps resolve the integration. Feel free to follow up if you have further questions.