I have an API that will be called from back-end applications as well as a mobile app. I am confused about token generation from these applications. Which one of these is the correct approach:
The back-end application uses the Client Credentials grant (CCG) to obtain an Access Token, the mobile app uses the Authorization Code Flow with PKCE (ACF) to obtain an Access Token. Both applications use their respective tokens to call the API. The API does not need special handling for different types of tokens - they are all verified the same way.
The back-end application uses the CCG to obtain an Access Token, and calls the API. The mobile app uses ACF to authenticate the user, and then uses CCG to obtain an Access Token to call the API. The API only accepts tokens generated using CCG, and rejects other tokens. Is there anything in the token to differentiate how it was generated? Should it matter to the API?
I hope my question is clear. I am open to discussion.
The authentication flows / grant types used don’t matter to the API, all that matters in the end is the token, which it needs to verify. The verification is based on signature of and claims within the token. That’s all that matters, not in which way the token has been requested.
This docs (and further linked pages) describe what standard claims to verify.
Luckily the SDKs and libraries available (which you can find at the bottom of page jwt.io), make such token verification easy due to available helper methods.
Is there anything in the token to differentiate how it was generated?
In a way, yes. With CCG, the sub claim will be a client id in the form of:
for example, while with ACF, it will be a user id. So, if a sub is a client (application) id, it’s a hint that this token has been requested via CCG, but as said, the grant type doesn’t matter, simply base it on claims in the token.