When requesting tokens via the /token endpoint, the "scopes" parameter is filled out with several requested scopes, but only a subset is granted when the token is minted.
- API Access Management
- OpenID Connect (OIDC)
- Tokens
- Scopes
When requesting OIDC Tokens through Authorization Code Flow or any flow requiring the use of the /authorize endpoint before the /token request, include the same scopes in both requests. Scopes can not be added to the /token request that were not included in the initial /authorize request because the code was not issued with those scopes granted at the time of authentication.
Check the system logs for the /token request, and expand to check for Requested and Granted scopes.
- Do this by searching the logs for /authorize calls in the time frame where this happened:
- Then, expand Event > System > DebugContext>DebugData or click Expand All to get to the Debug Data for the request:
- Scroll down to the GrantedScopes and RequestedScopes to see which scopes the authorization code was issued for:
- Similarly, for the Token Request, query for when that request was made, typically right after the /authorize call when an OIDC app is programmatically going through Authorization Code Flow:
- Expand the request as above:
- Then check the GrantedScopes and RequestedScopes here as well:
Based on this example, because the /authorize request only included the "openid" scope, the /token request only granted that scope, even if the "profile" scope was requested in the /token call. To fix this, simply request "profile" in the /authorize call as well as in the /token call, and then the tokens received will include the needed scopes.
NOTE: Queries can be performed without the "as" in the log query (that is, "app.oauth2.authorize.code" or "app.oauth2.token.grant.access_token" if using the Org Authorization Server), but this query will also include logs for first party apps like the Okta Dashboard and Admin app, so find the app to get the results as explained above.
