Understanding Azure Active Directory Authentication and Authorization using Oauth

{tocify} $title={Table of Contents}

What is Azure Active Directory?

Active directory is service offered from Azure for Identity management and Access management. 

In simple terms it is an identity store where in you store information of the users, groups, applications etc and provide access and permissions based on those information thus helping in securing the resources. It does it with help of RBAC, industry-standard protocols such as OAuth 2.0 and OpenID Connect etc.

Role-based access control (RBAC) is a authorization system that helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

Thus enabling right identities to access the right resources for right reasons.

To grant access, you assign roles to users, groups, service principals, or managed identities at a particular scope.

What is OAuth?

Wikipedia says OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authorization protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

It works by delegating user/client authentication to the service(Auth Server) that hosts the user account, and authorizing client/third-party applications to access the user account/applications i.e. only those who have successfully authenticated will be eligible for access.

How OAuth works with Azure Active Directory

Say you application/resource and you want it to be secured using OAuth, so the first step would be to select the Authorization server whom you assign the task of creating access token after validating the identity of the client.

Authorization server can be Facebook,  Azure AD etc the only requirement should be - client's identity should be registered with it i.e. auth server should know who the client is, only then access token would be granted. 

Thus in order for client to get access token to your resource it has to prove it's identity to Authorization server.

Oauth Protocol

In the picture above , generic flow happens as below

1. Client tries to access the resource

2. Resource asks client to get token from Authorization server

3. Client then request for access token from Authorization server, here Auth server first checks if this client has some identity registered with it(Authentication) or not.

4.  If authenticated then access token is granted to client else client is notified about permission issue.

An access token is a security token that is issued by an authorization server. It contains information about the user/client and the app/resource for which the token is intended.

It consists of three main parts: Header, Payload, and Signature. 

It is JSON based tokens (JWTs) that contain claims in Payload. A claim consists of key-value pairs that provide information such as:
Security Token Server that generated the token.
token generation date
audience - which is the app/resource for which the token was generated.
the app (the client) that asked for the token. 

They are base64URL encoded and separated by a dot(.). You can use any base64URL decoder available to parse the token.

5. Client now presents the access token to resource to get the access

6. Resource can itself validate or check with Auth server for checking the authorization_code is intact, not altered, not expired and issued for that specific client. 

So when we use Azure active directory as Authorization server and request for access token is sent to it,it will first check if the user or the client requesting is registered with it or not. i.e. is their identity present in active directory or not.

Above is the basic flow, however based on the type of application  and user's involvement(consent) below are  flows/grant types

1. Implicit Grant Flow
2. Auth code grant
3. On behalf of flow
4. Client credentials grant - Example of client credentials grant flow
5. Device code flow
6. Resource owner password credentials grant

More about types of grants can be learn from MSDN article - Authentication flows app scenarios

If you have questions or suggestions, feel free to do in comments section below !!!

Do share if you find this helpful .......
                          Knowledge Sharing is Caring !!!!!!


If you have any suggestions or questions or want to share something then please drop a comment

  1. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
    This statement is incorrect. OAuth is authorization protocol.

Previous Post Next Post