This section discusses the following issues and workaround:
Section 30.12.2, Token Exchanges Show Redirect URI Invalid Error
Section 30.12.3, Users Cannot Register or Modify a Client Application with Specific Options
Section 30.12.4, A Specific Claim Does Not Come to the UserInfo Endpoint during Claims Request
Section 30.12.6, After Allowing Consent, 500 Internal Server Error Occurs
Section 30.12.7, No Error Message When a Token Request Contains Repetitive Parameters
Section 30.12.8, Oauth Token Encryption/Signing Key Is Compromised or Corrupted
Section 30.12.11, The Identity Injection Policy Does Not Inject Passwords
Section 30.12.12, OAuth Apps Fail After Upgrading Access Manager
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.
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.
Verify the options enabled for the client application. An administrator must enable same options in the Global Settings page.
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.
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.
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.
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.
Regenerate the token encryption/signing key by using the following steps:
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
Go to Administration Console and click Devices > Identity Server > Edit.
Update Identity Server cluster.
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.
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
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.
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.