Troubleshooting OIDC

The mobile app makes a call to https://connections.example.com/mobile/homepage/SecurityConfiguration to discover how it should login to the Connections server. When using OAuth, this response should contain the following keys at a minimum.

"AuthType":"OAuth"

"OAuthAuthorizationURL":"https:\/\/login.microsoftonline.com\/0d627c55-8753-467d-bb74-dfaea2514025\/oauth2\/v2.0\/authorize"

"OAuthTokenURL":"https:\/\/login.microsoftonline.com\/0d627c55-8753-467d-bb74-dfaea2514025\/oauth2\/v2.0\/token",
"OAuthClientId":"7789999d-d8dc-40bf-a710-ae0f396928b5"
"OAuthScopes":"openid offline_access"

Use a browser to open the pagehttps://connections.example.com/mobile/homepage/SecurityConfiguration?debug=true and verify that the correct configuration keys and values are displayed.

When this step occurs, you should see your OpenID login page within the mobile app. Enter whatever credentials are required for login.

If you do not see this page, validate that the endpoint URL specified by OAuthAuthorizationURL is correct and is accessibile from the same network that your device is using. You can troubleshoot this step by using the web browser on your mobile device and attempt to access the exact same URL. Validate that you are able to access the OpenID login page.

This step will not be visible to the end user on the device. However, if the web login page is never closing, then it could be possible that you have not defined the callback URL within the OIDC client registration for the Connections mobile app properly. The mobile app is looking for this callback redirection, so that it knows to close the authorization phase and move to the token retrieval phase.

Using the JWT as a bearer token, make a request to the Connections server API /mobile/homepage/Configuration. This request is the first API in a sequence that requires authentication at the Connections mobile server. This request needs to be processed by the WebSphere Relying Party TAI, and the JWT that is present on the request must be validated, converted to an internal user identity that Connections understands, and a session cookie (LtpaToken2) should be set on the session.

During the initial setup, it is not uncommon for some configuration setting to require adjustment to support the JWT coming from the OpenID Provider.

If this stage fails, an error is typically displayed on the mobile app indicating that the connection failed to the Connections server.

To troubleshoot this stage, perform the steps below:

1. Enable the following traces in the WebSphere mobile server:

   com.ibm.ws.security.oidc.*=all:com.ibm.ws.security.openidconnect.*=all:com.ibm.ws.security.web.*=all

   Refer to the TroubleShoot: OpenID Connect, WebSphere traditional article for details for general OIDC troubleshooting .

2. Find in your trace the following lines:

   … RelyingParty  3   The URL: [https://connections.example.com/mobile/homepage/Configuration] accepted by OIDC RelyingParty
   … RelyingParty  <  ==> OIDC: isTargetInterceptor returns [true] Exit
   

   If you find this URL is ignored by the Relying Party, then the intercepting filter must be incorrect. Note that you may find that you see the mobile app making requests to /mobile/oauth/homepage/Configuration. This is expected to fail and can be ignored.

3. Once found, you should find the following just below the above lines:

   … RelyingParty  3   Authorization header=<some long token>

4. Copy the Bearer token and load into a JWT decoder, such as the one from https://jwt.io.

5. Paste the Bearer token into the decoder. You will be able to see all of the claims that are provided in the JWT. This will allow you to ensure that you OpenID Provider is actually inserting the expected “iss” and the field you have selected for the userIdentifier field, such as “email”.

6. Check if the following lines are displayed after. If not, then most likely you have not set provider_1.isJwtRequired=true.

   … RelyingParty  3   ==> OIDC: AUTENTICATING USING JWT

7. The next batch of lines typically comes from the OIDC RelyingParty. Look for errors, such as failing to retrieve the JSON web key set from the jwkEndpointUrl. Or other errors that are displayed, up until you find the line.

   … RelyingParty  3  ==> OIDC: PROCESS COMPLETE

8. If no errors are encountered prior to the OIDC: PROCESS COMPLETE message, then the next set of lines to expect are with mapping the credentials. You can see something similar to the following if the user is mapped into the user realm that WAS and Connections are using.

   … WebAuthentica 3   Username retrieved from TAI is [john.doe@example.com]
   … WebAuthentica 3   Map credentials for john.doe@example.com.
   … WebAuthentica 3   Mapped credential for TrustAssociation was validated successfully.