OpenID Connect (OIDC) Applications in Okta allow end-user applications to obtain an optional refresh_token. Best security practices suggest rotating this refresh_token after each use, which is the default in Okta.
At times, applications can get out of sync and attempt to reuse a refresh_token. Troubleshooting when this happened in the application can be difficult since the refresh_token value is not logged in Okta. This is for security reasons. Instead, Okta logs the hash value of the token in the system log. This article describes how to hash a raw refresh_token value and then check the Okta logs with the hashed value.
- OpenID Connect (OIDC)
- refresh_token
In order to compute the same hash value of the refresh_token Okta uses in the system logs, the raw value of the refresh_token needs to be obtained from the application. How this is done will be application-specific. Backend applications might provide a means of logging this information.
For public applications that use the okta-auth-js SDK, the refresh_token value can be obtained by inspecting the network calls to the authorization server's token endpoint. Additionally, the value can be viewed in the browser's token storage or retrieved from the TokenManager API provided by the SDK.
The below assumes the refresh_token raw value is zDfsxCWXNo0QE4MtMZ2TM1je2Ofkgis47rizYbbW2Bk
Using this value, the below command produces the same hash value that Okta logs for this refresh_token in the system log.echo -n "zDfsxCWXNo0QE4MtMZ2TM1je2Ofkgis47rizYbbW2Bk" | shasum -a 256 | xxd -r -p | base64- The output from above will be
hFq1PH4oWPp8F6maiAzaXiCC6i6GbT5PHnKA77192tc= This value can then be used in the system log query below to see when the refresh_token was minted.eventType eq "app.oauth2.as.token.grant.refresh_token" and target.detailEntry.hash eq "hFq1PH4oWPp8F6maiAzaXiCC6i6GbT5PHnKA77192tc="
- The output from above will be
