Support for pairwise subject in CIBA flow

Seems that pairwise subject type does not work well with the CIBA flow. Thus, if the id token has the subject as pairwise and we go through the CIBA flow, the /access_token endpoint fails with

Caused by: org.forgerock.oauth2.core.exceptions.NoUserExistsException: Not able to read user information.
at org.forgerock.openam.oauth2.IdentityManager.getResourceOwnerIdentity(
at org.forgerock.openam.oauth2.IdentityManager.getResourceOwnerOrClientIdentity(
at org.forgerock.openam.oauth2.token.OAuth2ScriptHelper.getUsersIdentity(
at org.forgerock.openam.oauth2.token.OAuth2ScriptHelper.getIdentityAndScopes(
at org.forgerock.openam.oauth2.OpenAMScopeValidator.initScriptBindings(
at org.forgerock.openam.oauth2.OpenAMScopeValidator.modifyAccessToken(
at org.forgerock.oauth2.core.RealmOAuth2ProviderSettings.modifyAccessToken(
at org.forgerock.openam.oauth2.token.OpenAMTokenStore.saveNewAccessToken(
at org.forgerock.oauth2.core.BackChannelGrantTypeHandler.createToken(
at org.forgerock.oauth2.core.BackChannelGrantTypeHandler.handle(

From the documentation seems that Forgerock AM uses guidelines provided by Financial-grade API (FAPI) WG | OpenID for CIBA implementation and there is no mention of pairwise there.

Is there any patch or config available to have this working ?

Hi Joshfr,

Can you check that your Subject Type = pairwise in the client, and your OAuth server settings also support pairwise for Subject Type?

Please see: ForgeRock Access Management 7.1.2 > Reference > Global Services Configuration

Subject Type
Specify the subject identifier type, which is a locally unique identifier that will be consumed by the client. Select one of two options:

  • public. Provides the same sub (subject) value to all clients.
  • pairwise. Provides a different sub (subject) value to each client.

Based on the error message, appears there could be an issue with accessing the user’s profile. If the above settings are already in place, you may wish to raise a Support ticket for further investigation.

Please see:

I hope this information helps.


Thanks Sheila for the response. Yes, we do have that configuration and the sub claim is indeed pairwise in the id token. However, when we pass that id token as a hint to the /access_token endpiont (for CIBA flow) , it fails.
I tried debugging and found this in the forgerock code and seems the pairwise is not catered for.

public String getUsernameFromTokenHint(OAuth2Request request, String tokenHint) throws InvalidRequestException {
    if (StringUtils.isBlank(tokenHint)) {
        throw new InvalidRequestException("no id_token in request");
    } else {
        try {
            OAuth2Jwt oauth2Jwt = this.constructOAuth2JwtFromIdTokenHint(request, tokenHint);
            return oauth2Jwt.getSubject();
        } catch (ServerException | InvalidJwtException | SSOException var4) {
            logger.error("Invalid id token tokenHint provided: " + var4.getMessage());
            throw new InvalidRequestException("Invalid id token tokenHint provided");

But ya, thanks - we will raise a support ticket.


Thank you for those follow-up details, Josh.

To expedite time to resolution when raising a ticket, you’ll want to capture the following debug information while reproducing the issue, and attach the files to the Support ticket:

Reproduce the issue in Message level debug mode and capture a HAR file while reproducing.

Prior to reproducing the issue: (Clear out AM debug logs and enable Message level debugging mode).

Attach the following when raising the Support ticket:

  • Export of AM configuration

  • AM Message Level logs from /debug:

  • HAR file

Assuming your deployment type is FR Identity Platform Access Management. If you’re deployed on Identity Cloud please let me know as the instructions will differ for raising a ticket :

Please see the following KB articles for instructions on capturing the data:

Thank you and kind regards,


1 Like