Fix invalid id token issue in WSO2 Identity Server 5.11.0

When you are setting up Wso2 Identity Server 5.11.0, you might have come across an error in the console of your browser saying “Invalid id_token in the token response” when running either the My Account app or the Console app, which is currently in the beta version. This, as the name implies, is due to errors when validating the id token returned by the identity server. This article proposes possible solutions to this problem.

The My Account app and the Console app use the OIDC protocol to authenticate users. As per the protocol, the identity server returns the JWT id token along with the access token on successful authentication. The validity of the id token is then evaluated by the apps using the public keys returned by the jwks endpoint of the identity server to verify the token signature. In addition to verifying the signature, the apps also perform some additional verifications according to the OIDC specifications. It is here where things could go wrong.

Two common scenarios could throw the “Invalid id_token in the token response” error in the browser console. Let’s look at them both.

Wrong issuer

The issuer in OIDC is an entity that issues a set of claims. This is often the base URL of the identity server. The OIDC specification requires that the issuer denoted by the iss attribute in the payload of the id token, the issuer URL that was used to fetch the OIDC configuration details, and the issuer in the OIDC configuration should all be identical.

Before initiating an authentication request, the apps obtain the OIDC configuration details from an endpoint. This configuration gives you the endpoints for sending requests for authorization, token, logout, etc. The apps use this information to successfully carry the process of authenticating a user off.

This configuration also contains the issuer URL. This URL should form the base of the URL of the endpoint from which the OIDC configuration was obtained. Then, once the authentication is complete, you get an id token. The payload of this id token also contains the issuer URL. This should also be the same as the issuer in the OIDC configuration. So, in summary, all three issuer URLs should match.

Where does it go wrong?

The URLs will match without a problem unless you use a reverse proxy like Nginx to deploy the identity server. When setting up a proxy, you might use a setting such as this in the deployment.toml file.

[transport.https.properties]
proxyPort = "443"

This allows you to access the identity server using a custom name and without our port number 9443. For instance, you could configure the server so that it can be accessed through https://is.dev.wso2.com.

So, this URL would form the base of the URL of the endpoint that returns the OIDC configuration. It could be something like this: https://is.dev.wso2.com/oauth2/token/.well-known/openid-configuration. The issuer in the OIDC configuration returned by this endpoint will also contain the correct issuer, which might be something like this: https://is.dev.wso2.com/oauth2/token. So, we get two out of three right.

However, the problem occurs with the third issuer URL which is the one found in the payload of the id token. That could contain the https port number, which is 443, in the issuer URL. So, you might see something like this: https://is.dev.wso2.com:443/oauth2/token. This is what causes the id token validation to fail.

The issuer URL in the id token contains the port number because the Identity Provider Entity ID in the Resident identity Provider setting contains the port number. So, to fix this, we need to remove the port number from the Identity Provider Entity ID.

The fix

To do this, open the carbon console by going to https://<IS_HOSTNAME>/carbon. Then, select “Resident” under “Identity Providers” on the side panel. Next, expand “Inbound Authentication Configuration” followed by “OAuth2/OpenID Connect Configuration”. Here, you will be able to find the “Identity Provider Entity ID”.

Now, remove the port number from the URL and click on the update button. This should resolve the issue.

Wrong system time

If your system is wrong, then that can also result in validation issues. The id token contains an “nbf” (not before) and “expiry” parameters. The apps compare the system time with these parameters to see if the id token is valid. If your system time is either early or late, then it will result in the id token being invalidated. Of course, the obvious solution is to update your system time.

Hostname capitalization

If the hostname of the identity server is capitalized, then that can also cause id token validation to fail. This is because the carbon identity framework implicitly converts the hostname to lowercase characters, which results in the issuer URL in the OIDC configuration endpoint not being identical to the issuer returned by the id token. Here, it is important to note that the comparison is case-sensitive.

Unfortunately, this issue has not been resolved yet and the progress can be tracked here.