Hey @BernhardBln,
Welcome to the Auth0 Community!
There’s a lot of stuff here. Let’s go through them one at a time.
The diagram summarizes what is explained in the article and, as you can imagine, summarizing things is hard. Actually, the article barely mentions scopes. This is a more detailed article on scopes and related concepts.
You are right about the process of first checking the application’s scopes and then checking the user’s permissions (or better, privileges). The diagram’s summary focuses only on the final effect, not the process: determining whether or not the client is allowed to access a resource.
Related to the role question, you can add roles and even permissions to your access token using Actions. See this for more info. If your application is an API, you can configure it to include permissions in the access token.
In other words, you can have the following in your access token:
- application’s scopes (what the application wants to do)
- user permissions (what the user can do)
- user roles (collection of permissions or other criteria)
Your access control component can use all this information to make its authorization decisions.
Note: If in your authorization model “role” == “collection of permissions”, having roles in the access token will probably not add any more info. You can just rely on permissions, but that is another story.