This section discusses the following issues and workaround:
Users Cannot Register or Modify a Client Application with Specific Options
A Specific Claim Does Not Come to the UserInfo Endpoint during Claims Request
No Error Message When a Token Request Contains Repetitive Parameters
Oauth Token Encryption/Signing Key Is Compromised or Corrupted
OAuth Endpoint Generates Access and Refresh Tokens Using OAuth Resource Owner Credential Flow
In the Administration Console, verify whether the user has role NAM_OAUTH2_DEVELOPER or NAM_OAUTH2_ADMIN configured in the 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 the 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 the Administration Console and click Devices > Identity Server > Edit.
Update the 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 the 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 the 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 token endpoint generates access and refresh tokens using the OAuth resource owner credential flow when you specify a valid user name and a null password.
To fix this issue, check the eDirectory configuration. The configuration must not allow any anonymous logins. In eDirectory, you must validate ldapBindRestrictions: 0 (No Restriction)
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.