Roles vs permissions vs scope distinction

Help
1

Hi all,

First of all, I know that there are similar questions, but I’m really confused.
I have a NextJS frontend which calls a C# Web Api.
So in the dashboard i can configure roles, permissions and scope.

1.Why do I need to configure in a frontend call the scope (nextjs-auth0/examples/api-call-example at master_OLD · auth0/nextjs-auth0 · GitHub )? If you scroll down, you see following code:
const { accessToken } = await tokenCache.getAccessToken({
scopes: [‘read:shows’]
});

Couldn’t a user fake this?
I mean it’s unnecessary and a user can fake it. Why did auth0 introduce it? Couldn’t just check if the related token/user has the needed role?

Also in my API i check for the scope. Isn’t it possible to check for the role?

Also whats quite confusing me, is the authorization. Why do I need to add an authorization extension as an additional app? Now if I need to add/remove/update something, I need to do it in my api and the newly generated project from the auth extension, which also counts as an app or what?

1 Like
2

Hello @ibi,

Welcome to the Community!

Scopes are typically associated with API access. An API defines what scopes are available (what services it provides). For example a user account management API might define scopes like read:user, create:user, update:user. These are the capabilities the API provides, but not necessarily what any given user can do. In the “Role & Scope” model, Roles are defined, and users are given a Role. Individual Scopes are associated with a given Role, combining all these elements together. For example, you might have:

Role: Audit, API: user_manager, Scopes: read:user
Role: Access Control, API:  user_manager, Scopes: create:user, update:user

And maybe Alice has the Audit role, while Bob has the Access Control role.

When you request a scope, the Authorization Server (Auth0) will decide whether you get that scope or not. You can request anything you like, but the Authorization Server sends back a token with only the scopes it has decided your are allowed to have.

You do not need to use the Authorization Extension, and in general I would recommend not using it. Instead, use the core authorization feature now built in to Auth0.

3 Likes
3

Thanks a lot for your help.
So if I send a request from my frontend to my backend, Auth0 will know thats the User xyz with role xyz and therefore allow / won’t allow the resource, right?

4

Auth0 provides a lot of flexibility so there’s probably more than one way to handle this. The basic model that immediately comes to mind is:

  1. User tries to access Resource_A,
  2. Auth0 authenticates the user,
  3. After authentication one or more Auth0 Rules add authorized API scopes to the user’s ID and / or access token,
  4. Resource_A checks the token to see what scopes were authorized.

The actual flow is more complicated than this, but that is the gist. Use an ID token to grant access to an application. Use the access token to grant access to APIs. It is largely based on what data you include in your tokens, though you can also leverage the Auth0 management and / or authentication APIs directly as well.

4 Likes