Usage of scopes

[brunokrebs]

Howdy! I'm opening this issue to bring up an "issue" that you might decide to address or not. Scopes, as intended by the OAuth spec, exists so apps can request delegated access to some resource owned by the user. Apparently, this is not what you are doing in your sample. If I understood correctly you are adding scopes to work more or less like roles that authorize (or deny) access to a route and an endpoint in your API.

Well, I was going to elaborate more on that, but @auth0's Principal Architect have published an article about that. So I believe that you will be on better hands reading this.

[coryhouse]

Hi @brunokrebs - That's correct, I am. Thanks for the link. I understand the two core concerns conveyed in the post are:

1. Scopes were intended to convey what an app can do on a user's behalf
2. Using scopes for roles/permissions can lead to an impractically long list of scopes, and still requires the auth server to further validate context.

Fair summary?

Those are valid points. So what example would you suggest I use instead to convey the following?

1. Creating a scope
2. Using rule to set a scope for a specific user
3. Checking a scope in an auth token

I demo'd those three by giving all users read:course and a single user delete:course scope via a rule. Perhaps it's enough for me to keep the current demo but convey the caveats above?

[brunokrebs]

Yes, that's a good summary. Regarding an example to add scopes into your sample, I think that the read:courses might be a good example to show how an user delegates access so an app can consume its resources (courses in this case) from a resource server.

However, I'm failing to see a good example to use a rule (Auth0 Rule, I suppose) to set a scope for a specific user.

I'm just thinking here but, perhaps, you could change the approach a bit. You could add both read:courses and delete:courses to all users, however, each user could read and delete courses from its own private list of courses. Then, you could use an Auth0 Rule to add a role to an specific user saying that this user is an admin so your backend would allow they to read and delete courses from any user...

Hopefully, this will make sense.

PS: Sorry for the delay, on Friday, we were discussing how to approach the "unlucky" article written Torsten Lodderstedt.

[coryhouse]

Thanks Bruno. That's excellent feedback. I'm reframing my scope and rules demos based on your input.

I'm very interested to hear what you think the future is for the implicit grant. What are the changes it's going away any time soon? Would I be wise to rework my course to use the client credentials grant?

[brunokrebs]

No, no. Don't worry about that now. We were discussing how to address this article but we won't take any concrete action right now because the content was very misleading. For starters, the author doesn't make clear in the article that he is talking just about the OAuth 2 Implicit Flow and not about the OIDC Implicit Flow (this one won't change for the foreseeable future).

I can't give any time frame for changes to occur due to the problems reported by the author in relation to the OAuth 2 Implicit Flow, but the community has been using this grant for more than six year and, as such, this thing won't go away instantaneously...

Anyway, if you keep in touch with Auth0 (newsletter, Twitter, etc), then you will know in advance if we start changing anything in relation to that.

Well, I guess I will close this issue since we are synced in relation to scopes. Feel free to reopen or just ping me if you need any help.

Thanks!

[coryhouse]

@brunokrebs - Great to hear. Can you point me to the newsletter so I can sign up?

[brunokrebs]

I mean the blog newsletter: https://auth0.com/blog/ (just search for subscribe there)

If you subscribe to it, you will get notifications about all content that we post... including any article about changes that we might incorporate due to the deprecation notice mentioned (which might take several months).

[coryhouse]

"due to the deprecation notice mentioned" - Wait, deprecation notice for what? Have a link?

[brunokrebs]

Ooops, deprecation notice was not the best choice... due to the new recommendations (better now) afore mentioned (here and here).

[coryhouse]

@brunokrebs - Regarding your suggestion of assigning admin/user roles with a rule: The user's role is stored in the ID Token. So if I want to validate a user's role in an API call, the call would need to send the user's ID Token instead of their auth token. That smells wrong, since auth tokens are for APIs. Thoughts?

[brunokrebs]

My bad for the delay, hope I'm still on time. You can either add a custom claim (users' roles in this case) on both access tokens and id tokens. I have a rule that does exactly that (well, it adds on access tokens only):

function (user, context, callback) {
  user.app_metadata = user.app_metadata || {};

  if (user.email === 'bruno.krebs@auth0.com') {
    user.app_metadata.role = 'admin';
  } else {
    user.app_metadata.role = 'writer';
  }

  auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
    .then(() => {
      context.accessToken['https://rbac-tutorial-app/role'] = user.app_metadata.role;
      callback(null, user, context);
    })
    .catch((err) => {
      callback(err);
    });
}

For that to work you need, of course, to get the access token back from the authorization server alongside with the id token. Well, you can even get only the access token, but this is up to you and your impl.

P.S. Getting the access token in a SPA with the implicit flow is exactly what the OAuth working group is starting to advocate agains. But, so far this is the default approach and a better option was not delivered yet.

[coryhouse]

Hi Bruno - Perfect! I recorded adding the role claim to the access token via a role this morning, so great to hear. 😀

Good to hear implicit flow remains recommended for now. I've subscribed to the newsletter, but would certainly appreciate a ping if their advice changes.