Scopes are for delegated authorization with APIs, not for user roles or fine-grained permissions within a single app. A good way to think of this is that scopes are intended for application-level authorization. They aren’t meant to be tied to specific users, or user groups. Please check out this blog article to learn more about the details of OAuth 2.0 scopes.
Let’s say you have an API that you’ve built. For example’s sake, say the API is a movie streaming API. It accesses a database that contains many movies and provides various endpoints to do things like watch movies, or upload new ones. Let’s say there are two different applications that use this API: one of the apps is strictly a viewer for movies. While using it, users can only watch movies but not upload new ones. Maybe this is the public-facing streaming app. The other app lets its users view and/or upload new movies. This is the internal admin app for the owners of the streaming service.
Each of these applications receives different scopes: the API is delegating permission to the application. E.g., the viewer app for the public might get
read:movies only, while the admin app might get
read:movies write:movies. This grants application-level authorization to certain endpoints on the API.
When it comes to more low-level user permissions, keep in mind that scopes are not intended for individual access privileges at that level. If “texting” and “email” are associated to individual users or user groups, they can be API scopes, but you’ll need to grant both scopes to the entire application that contains all users with those scopes. Then you’ll need to implement authorization at the user level.
Auth0 provides a couple of ways to manage that level of user authorization. One way is to configure the authorization extension. Another way is to use your own custom claims. These features add claims to your users’ tokens; it’s important to know that it’s not a matter of your code “having to deal with two separate auth tokens.” Rather, the tokens will contain different pieces of data in their payload that your API can read and use to decide if the bearer of that token should have access to certain areas of your API.
Regarding authorized applications: these are applications with audiences that the user has granted consent to. If you don’t have an API audience for an application, there won’t be an authorized application listed. Users can still authenticate, it just means there wasn’t an API that the user granted access to.
Please let me know if these explanations make sense and if there’s anything else I can help with!