30.12 Troubleshooting OAuth and OpenID Connect

30.12.1 Users Cannot Register a Client Application

In Administration Console, verify whether the user has role NAM_OAUTH2_DEVELOPER or NAM_OAUTH2_ADMIN configured in Identity Server Role policy configuration.

Verify the REST communication between browser and Identity Server by using Chrome developer console.

30.12.2 Token Exchanges Show Redirect URI Invalid Error

Go to Administration Console > Devices > Identity Servers > Edit > OAuth & OpenID Connect > Client Applications. Open the client application and verify whether the specified URI is configured for the client application.

30.12.3 Users Cannot Register or Modify a Client Application with Specific Options

Verify the options enabled for the client application. An administrator must enable same options in the Global Settings page.

30.12.4 A Specific Claim Does Not Come to the UserInfo Endpoint during Claims Request

Verify the following points:

  • Whether the user has a value for that attribute. If the value is empty, UserInfo does not return any value in JSON.

  • The Identity Sever has provided the requested scope. You can check this with the TokenInfo endpoint by providing an Access token.

  • The scope contains the attribute mapping for the missing attribute.

    You can access only LDAP attributes as claims at this time.

30.12.5 Access Gateway OAuth Fails

Perform the following actions:

  • Verify whether Activate OAuth is selected for the Protected Resource.

  • Verify authorization policies are configured. Also, verify if the token contains required scopes by using the TokenInfo endpoint.

  • Verify Identity Injection policies. Enable Application debug logs in Identity Server and ESP and check for policy results.

30.12.6 After Allowing Consent, 500 Internal Server Error Occurs

Verify whether the attribute you have configured in the Global Setting page is available and stored in the user store. Ensure that the correct attribute to store authorization grant is available in the user store and it is writable to the user store.

30.12.7 No Error Message When a Token Request Contains Repetitive Parameters

Ensure that you do not send the same parameter multiple times in a single request. The base framework reads only last or first available parameters if multiple query parameters have the same name.

30.12.8 Oauth Token Encryption/Signing Key Is Compromised or Corrupted

Regenerate the token encryption/signing key by using the following steps:

  1. Delete the nidsOAuthKeysXML attribute from the e-Directory at the following location:

    o=novell, ou=accessManagerContainer, cn=nids, cn=cluster, cn=IDP_Cluster, cn=OAuth_Container

  2. Go to Administration Console and click Devices > Identity Server > Edit.

  3. Update Identity Server cluster.

30.12.9 Tracing OAuth Requests

You can trace each OAuth request and response by setting the following property in tomcat.conf.

Add the following line in /opt/novell/nam/idp/conf/tomcat.conf:

JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.oauth.jersey.trace=ALL"

You can specify the following parameters:

  • OFF: tracing support is disabled (default value)

  • ON_DEMAND: tracing support in a stand-by mode. It is enabled selectively per request through a special X-Jersey-Tracing-Accept HTTP request header. The Jersey tracing facility does not use the value of the X-Jersey-Tracing-Accept header and as such, it can be any arbitrary string.

  • ALL: tracing support is enabled for all requests

You can customize the level of detail of the information (tracing threshold) provided by Jersey tracing facility. You can set the tracing threshold at a request level through X-Jersey-Tracing-Threshold HTTP request header. The request level configuration overrides any application level setting. Supported levels include SUMMARY, TRACE, and VERBOSE.

  • SUMMARY: basic summary information about the main request processing stages

  • TRACE: detailed information about activities in all main request processing stages (default threshold value)

  • VERBOSE: extended information similar to the TRACE level, however it includes details about entity providers (MBR/MBW) that were skipped during the provider selection phase for any reason (such as lower priority or pattern matching). Additionally, in this mode all received request headers are echoed as part of the tracing information.

For more information, see Monitoring and Diagnostics.

30.12.10 OAuth Client Registration Fails If a Role Policy Contains a Condition Other than LDAP Attribute, LDAP Group, or LDAP OU

For registering OAuth client applications by using Identity Server, you must have a role called NAM_OAUTH2_DEVELOPER assigned.

The following are the recommended conditions in an Identity Server Role policy that assigns the NAM_OAUTH2_DEVELOPER role:

  • LDAP Attribute

  • LDAP Group

  • LDAP OU conditions

The client registration will not work if this role policy contains any of the following conditions:

  • Authenticating IDP

  • Authentication Contract

  • Authentication Method

  • Authentication Type

  • Credential Profile

  • Liberty User profile

  • Roles from Identity Provider

  • User Store

30.12.11 The Identity Injection Policy Does Not Inject Passwords

Verify logs by enabling the debug level. Verify whether, in Identity Server, the userinfo request is coming with sp-id. Logs should include the fetching password for user term. If any issue occurs, the log includes the error message.

30.12.12 OAuth Apps Fail After Upgrading Access Manager

The OAuth apps fail after you upgrade Access Manager. This is caused due to the expired authorization code.

To workaround this issue, you need to upgrade both Access Gateway and Identity Server to Access Manager at the same time. For more information, see TID.