CODEWITHSUNDEEP
azureoauth-2.0azure-active-directoryauthorization
mnj
mnj

Reputation: 3413

user_impersonation scope - why?

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) - the Resource Server has to find permissions in some data base related to the provided userId in the token.

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.

Upvotes: 2

Views: 17899

Answers (1)

Imran
Imran

Reputation: 5520

For the API permissions of most of the services in Azure Portal, you can see User_Impersonation delegated permission. This is because user_impersonation permission is enough to access that particular service API on behalf of the signed user

For the other services like Microsoft Graph, you can see many other permissions like user.read, user.readwrite etc.,

While generating the access token in OAuth flow, you can add the scope with the permissions added for the app registration. The token will be generated with these permissions.

Upvotes: 5

Related Questions