SPA + API tutorial removes default scopes

[fons]

I’m building a web app + API type of setup, and using the Auth0 Authorization Extension. In the article Auth0 Configuration (SPAs + API) there’s a Rule that removes all scopes that are not in the user’s permissions (according to Authorization Extension):

function (user, context, callback) {
  var permissions = user.permissions || [];
  var requestedScopes = context.request.body.scope || context.request.query.scope;
  var filteredScopes = requestedScopes.split(' ').filter( function(x) {
    return permissions.indexOf(x) > -1;
  });
  
  context.accessToken.scope = filteredScopes;

  callback(null, user, context);
}

The effect it has, though, is that it also removes the scopes “openid profile email”, which are standard but I cannot add to the Authorization Role. Is it correct in thinking that I must “escape” this by hand, and that this piece of code is erroneous in that it should take this into account? Or is there another way of “escaping” this?

[kim.maida]

The openid profile email scopes are for ID tokens. The intent of the validation of token scopes is for API authorization, which concerns access tokens. This rule will indeed remove those scopes from an access token, but it should not affect the ID token, see:

context.accessToken.scope = filteredScopes;

Therefore, there should not be a need to escape these scopes.

On that note, the Rules in the docs and Rules templates are examples, and can be modified to your needs. If you need to make some changes in your implementations, please don’t hesitate to do so. In this case, however, you should not need to.

[fons]

Thanks for getting back so quickly and explaining the difference between ID token and access token.

I did some more experimenting and figured out that, in the Authorization Code Grant flow in Python, the /userinfo endpoint is called using the access token, which needs these scopes to be present to retrieve the ID token from /userinfo.

So I understand that if I want this to work without escaping these scopes in the rule, I must get the ID token at the same time as the access token. I can do that by setting response_type to token id_token in an API call.

However, authlib currently uses the code response type, and attempting to use token id_token instead doesn’t work. Can’t easily find the answer in the docs either. Would you know how to use token id_token response_type with authlib?

[kim.maida]

Thanks for the additional information regarding stack and flow you’re using, that helps!

In this case, the easiest and most straightforward solution will be to escape openid profile email in the rule, since Authlib retrieves Auth0 userinfo by calling the /userinfo endpoint. (The ID token could also be decoded to acquire the payload, which would negate the need to call the userinfo endpoint).

If the library has easy config to tell it to exchange the code for both tokens and then decodes the ID token, then you can simply use that payload to acquire user information and skip calling /userinfo, though I’m not familiar enough with the Authlib library to say whether it does this out of the box with some simple config options.

However, as mentioned, it’s perfectly reasonable (and even expected) that you modify Rules templates and examples to suit your use case, so not filtering those scopes out is a very logical solution.

[fons]

Great, thanks for the clarification! Glad this solution makes sense, getting more and more comfortable with customizing my setup.