OAuth 2 in AzureAD - nordvall/TokenClient GitHub Wiki

Capabilities

Azure AD plays the Authorization Server role in OAuth 2 terms, and sometimes also the Resource Server role (when a Client wants to get access to user data in AzureAD).

Azure AD has it's own twist in the grant of permissions.

  • When the Client and the Resource Server are registered in the same AzureAD instance (tenant), the administrator grants the access once for all users. That is done via the "WebApi this Client can access" setting.
  • When the Client and the Resource Server are registered in different AzureAD instances (tenants), an administrator also grants the access once for all users. This is done via an ordinary consent page.

Maybe this makes sense in an enterprise perspective. If the company develops its own application, to be used to access company data in another application, the comany could grant this permission once for all.

Permission scopes are not used here, except when granting access to AzureAD itself (Read or Read/Write).

Supported flows

AzureAD supports these flows:

OAuth grant AzureAD support
Authorization Code Supported
Implicit Not supported
Client credentials Supported
Resource owner password credentials Supported

Endpoints

Token endpoint: https://login.windows.net/instanceguid/oauth2/token

Authorization endpoint: https://login.windows.net/instanceguid/oauth2/authorize

Glossary

OAuth 2 term AzureAD name
Resource Server Application
Client Application

Both Clients and Resource Servers are considered as Applications in Azure AD. The motivation is that for example web application can both

  • provide data to other applications (be a Resource Server)
  • consume data from applications (be a Client).

The granted permissions, that means the combination of client, user and resource, are stored in AzureAD as a Permission-object.

External references