Scopes - any best practices?

[mnj]

Usually, when reading about OAuth2, you can find information that the permission should be defined in scopes to state exactly what is needed. I recently looked into how Microsoft does that in their Azure Portal. It turns out that the only scope I get when accessing the portal is “user_impersonation”. Why is that? My guess is that the token would be too big if they included all the permissions as scopes?

More generally, it seems to me that there are at least two approaches to dealing with authorization in OAuth2:

1. Store all permissions in the token - the Resource Server just looks at the token to decide what data to expose
2. Store limited information in the token (like userId) - In such a case, there would probably be some kind of API/UI to manage permissions assigned to a user. The resource server would have to reach out to the API/DB storing these permissions for users to understand what should be allowed

It seems that Microsoft is using the second approach. Unfortunately, I didn’t find any information about that way of doing auth. Are there some good resources to read about it? Until now, as I said, all resources I read say that you should include the permissions as scopes. It seems valid, but probably not doable in some more complex scenarios?

[tyf]

Hey @mnj, great question!

@mnj

Usually, when reading about OAuth2, you can find information that the permission should be defined in scopes to state exactly what is needed. I recently looked into how Microsoft does that in their Azure Portal. It turns out that the only scope I get when accessing the portal is “user_impersonation”. Why is that? My guess is that the token would be too big if they included all the permissions as scopes?

Here’s a great blog post of ours that goes into this a bit: On The Nature of OAuth2’s Scopes and another community thread which may prove useful as well.

Hope this helps!