The user tokens contain always all permissions assigned to the user. Scopes on the other hand are only included if they are requested during the authentication process.
In case of applications I can enable to include permissions but the scopes are still included and I end up with all the information duplicated.
I’m wondering if there is any reasoning behind this. Is it necessary for some reason to differentiate between scopes and permissions even tough they are effectively the same?
I’m also a bit concerned about the token size. I’m afraid to hit hit a token size limit at some point if everything included twice.
Thanks for helping me to understand the concepts here!
I would go either with the scope or permissions claim, not both simultaneously. If you send the /authorize call with the scope parameter added, then you can expect the scope claim to be added by default to the access token, so in that case, I would skip adding the permissions claim (as it’s optional).
The advantage of adding the scope parameter to the /authorize call is that the user, while logging in, will be shown a consent screen with all the requested by the calling application scopes (so they can accept or revoke the access for the application). → In the case of first-party applications (a scenario where both a calling application and the API are registered on your Auth0 tenant or the calling application and your API are on the same domain), the consent screen can be skipped, though.
If the access token includes the permissions claim, it will contain only permissions of your custom API that the calling application specifies as the audience. (The user may also have permissions of another API, but that won’t be included there for the transaction. )
That’s right
Please let me know if that clears your concerns or if you have any other questions on that.
