Implement user authentication and authorization

Last Updated on August 12, 2021 by Alam Mohammed

Implement user authentication and authorization is part of Implement Azure security topics. The total weight of this in the exam will be 15-20%. This training post is designed to help and provide readers with a better understanding of the topic mentioned.

Disclaimer: This is not a training article to help complete the Microsoft Azure AZ-204, but it provides a good insight into the areas within these topics. Labs and hands-on work are essential to passing most Microsoft Azure exams.

Implement user authentication and authorization:
implement OAuth2 authentication

Implement user authentication and authorization

Understanding the OAuth 2.0 implicit grant flow in Azure AD

The OAuth 2.0 authorization code grant relies on two separate endpoints:

  • The authorization endpoint: used during the user interaction phase
    • The token endpoint: used by a client to exchange the authorization code for an access token and, optionally, refresh tokens

The OAuth 2.0 implicit grant is a variant of an authorization grant:

  • It allows the client to obtain an access token (and id_token, when using OpenID Connect) directly from the authorization endpoint, without relying on the token endpoint
    • It never returns refresh tokens to the client
    • It is intended for JavaScript applications running in a browser (such as SPAs)
    • It should not be used for:
      • Native clients
      • Web applications that include a back end and consume an API from the back-end code

Authorize access to Azure AD web applications by using the OAuth 2.0 code grant flow

1. Register your application with your Azure AD tenant

Demonstrate registering an app with an Azure AD tenant as you describe the process of authorizing access to Azure AD web applications that use the OAuth 2.0 code grant flow.

2. Request an authorization code

Point out that the authorization code flow begins with the client directing the user to the /authorize endpoint. In this request, the client indicates the permissions it needs to acquire from the user. You can get the OAuth 2.0 authorization endpoint for your tenant by selecting App registrations > Endpoints in the Azure portal. At this point, the user is asked to enter their credentials and consent to the permissions requested by the app in the Azure Portal. After the user authenticates and grants consent, Azure AD sends a response to your app at the redirect_uriaddress in your request with the code.

3. Use the authorization code to request an access token

Now that you’ve acquired an authorization code and have been granted permission by the user, you can redeem the code for an access token to the desired resource, by sending a POST request to the /token endpoint. Azure AD returns an access token upon a successful response. To minimize network calls from the client application and their associated latency, the client application should cache access tokens for the token lifetime that’s specified in the OAuth 2.0 response. To determine the token lifetime, use either the expires_in or expires_on parameter values. If a web API resource returns an invalid_token error code, this might indicate that the resource has determined that the token is expired. If the client and resource clock times are different (known as a “time skew”), the resource might consider the token to be expired before the token is cleared from the client cache. If this occurs, clear the token from the cache, even if it’s still within its calculated lifetime.

4. Use the access token to access the resource

Now that you’ve successfully acquired an access_token, you can use the token in requests to web APIs by including it in the Authorization header.

5. Refresh the access token

Access Tokens are short lived and must be refreshed after they expire to continue accessing resources. You can refresh the access_token by submitting another POST request to the /token endpoint, but this time providing the refresh_token instead of the code. Refresh tokens are valid for all resources that your client has already been given consent to access— thus, a refresh token issued on a request for resource= can be used to request a new access token for resource= Refresh tokens don’t have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action. Your application needs to expect and handle errors returned by the token issuance endpoint correctly. When you receive a response with a refresh token error, discard the current refresh token and request a new authorization code or access token. In particular, when using a refresh token in the authorization code grant flow, if you receive a response with the interaction_required or invalid_grant error codes, discard the refresh token and request a new authorization code.

Service-to-service calls using client credentials

In this scenario, the client is typically a middle-tier web service, a daemon service, or a website. For a higher level of assurance, Azure AD also allows the calling service to use a certificate (instead of a shared secret) as a credential.

The slide illustrates how the client credentials grant flow works in Azure AD.

  1. The client application authenticates to the Azure AD token issuance endpoint and requests an access token.
  2. The Azure AD token issuance endpoint issues the access token.
  3. The access token is used to authenticate to the secured resource.
  4. Data from the secured resource is returned to the client application.

Common authentication flows

Interactive:User authenticates by using a web browser
On-Behalf-Of:Application authenticates on behalf of a user
Client credentials:Application authenticates by using pre-generated credentials
Device code:User authenticates on another device


Implement user authentication and authorization:
create and implement shared access signatures

Implement user authentication and authorization

Shared Access Signatures

žA Shared Access Signature (SAS Token) is a URI that grants access to a protected contaAllows client application to access a resource without using the storage account key.

  • iner, blob, queue, or table for a specific time interval
    • žShould only be used with secure (HTTPS) requests

žCan be generated with the following components:

  • žStart Time
  • žExpiry Time ž
  • Permission Levels (Read, Write, Delete, List, None)

Establishing a stored access policy

A stored access policy provides an additional level of control over service-level Shared Access Signatures (SASs) on the server side. Establishing a stored access policy serves to group shared access signatures and to provide additional restrictions for signatures that are bound by the policy. You can use a stored access policy to change the start time, expiration time, or permissions for a signature, or to revoke it after it has been issued.

Shared Access Signatures (SASs)

A Shared Access Signature (SAS) is a URI that grants restricted access rights to containers, binary large objects (blobs), queues, and tables for a specific time interval. By providing a client with a Shared Access Signature, you can enable them to access resources in your storage account without sharing your account key with them.

Blob URI address of the blob. Note that using HTTPS is highly recommended.
Storage services versionsv=2012-02-12For Azure Storage services version 2012-02-12 and later, this parameter indicates the version to use.
Start timest=2013-04-29T22%3A18%3A26ZSpecified in an International Organization for Standardization (ISO) 8061 format. If you want the SAS to be valid immediately, omit the start time.
Expiration timese=2013-04-30T02%3A23%3A26ZSpecified in an ISO 8061 format.
Resourcesr=bThe resource is a blob.
Permissionssp=rwThe permissions granted by the SAS include Read (r) and Write (w).
Signaturesig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3DThe signature authenticates access to the blob. It is a Hash-based Message Authentication Code (HMAC) function computed over a string to sign and a key by using the SHA256 algorithm and then encoded by using Base64 encoding.

Stored access policies

A Shared Access Signature can take one of two forms:

An ad hoc SAS. When you create an ad hoc SAS, the start time, expiration time, and permissions for the SAS are all specified in the SAS URI (or are inferred in the case where the start time is omitted). This type of SAS can be created on a container, blob, table, or queue.

An SAS with a stored access policy. A stored access policy is defined on a resource container—a blob container, table, or queue—and can be used to manage constraints for one or more Shared Access Signatures.

SAS token generation from a stored access policy

When you associate an SAS with a stored access policy, the SAS inherits the constraints—the start time, expiration time, and permissions—that were defined for the stored access policy.

The difference between ad hoc SAS and a stored access policy is important for one key scenario: revocation. An SAS is a URL, so anyone who obtains the SAS can use it, regardless of who requested it. If an SAS is published publicly, it can be used by anyone in the world. Stored access policies give you the option to revoke permissions without having to regenerate the storage account keys. Set the expiration on these to a very long time in the future (or infinitely), and make sure it’s regularly updated to move it further into the future.



Implement user authentication and authorization:
register apps and use Azure Active Directory to authenticate users

Implement user authentication and authorization

Azure Active Directory

Microsoft Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. Azure AD creates and manages credentials that help enterprise users sign in and access both internal and external resources that are offered by your company or third-party companies more securely. Azure AD’s geographically distributed architecture combines extensive monitoring, automated rerouting, failover, and recovery capabilities, which deliver company-wide availability and performance to customers.

Active Directory Authentication Library (ADAL)

For clients that need to access protected resources, Azure AD provides the Active Directory Authentication Library (ADAL). ADAL v1.0 enables application developers to authenticate users to cloud or on-premises

Active Directory (AD) and obtain tokens for securing API calls. ADAL makes authentication easier for developers through features such as:

  • Configurable token cache that stores access tokens and refresh tokens.
  • Automatic token refresh when an access token expires, and a refresh token is available.
  • Support for asynchronous method calls.

Creating an authentication context by using ADAL

First, you initialize your app’s AuthenticationContext, which is ADAL’s primary class.AuthenticationContext is where you pass ADAL the coordinates it needs to communicate with Azure AD and tell it how to cache tokens.

Acquiring an Azure AD token by using ADAL

The basic principle behind ADAL is that whenever your app needs an access token, your app simply calls authContext.AcquireTokenAsync(…), and ADAL does the rest. When your app requests a token by calling AcquireTokenAsync(…), ADAL will attempt to return a token without asking the user for credentials. If ADAL determines that the user needs to sign in to get a token, it will display a login dialog, collect the user’s credentials, and return a token upon successful authentication. If ADAL is unable to return a token for any reason, it will throw an AdalException.

Application registration

Note that registering an application is a necessary step, which involves telling Azure AD about the application, including the URL where it’s located, the URL to send replies after authentication, and the Uniform Resource Identifier (URI) to identify the application. Azure AD needs to communicate with the application when handling sign-on or exchanging tokens. The information passed between Azure AD and the application includes the following:

  • Application ID URI – The identifier for an application. This value is sent to Azure AD during authentication to indicate which application the caller wants a token for. Additionally, this value is included in the token so that the application knows it was the intended target.
  • Reply URL and Redirect URI – For a web API or web application, the Reply URL is the location where Azure AD will send the authentication response, including a token if authentication was successful. For a native application, the Redirect URI is a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request.
  • Application ID – The ID for an application, which is generated by Azure AD when the application is registered. When requesting an authorization code or token, the Application ID and Key are sent to Azure AD during authentication.
  • Key – The key that’s sent along with an Application ID when authenticating to Azure AD to call a web API.

In addition, Azure AD needs to ensure that the application has the required permissions to access your directory data, other applications in your organization, and other resources.

Authentication endpoints

Some additional considerations exist when developing a multitenant application instead of a single-tenant application. In particular, if you’re making an application available to users in multiple directories, you need a mechanism to determine which tenant they’re in. To accomplish this task, Azure AD provides a common authentication endpoint where any multitenant application can direct sign-in requests instead of a tenant-specific endpoint. This endpoint is for all directories in Azure AD, while a tenant-specific endpoint might be The common endpoint is especially important to consider when developing your application because you’ll need the necessary logic to handle multiple tenants during sign-in, sign-out, and token validation.


Implement user authentication and authorization:
control access to resources by using role-based access controls (RBAC)

Implement user authentication and authorization

What is Azure role-based access control (Azure RBAC)?

Access management for cloud resources is a critical function for any organization that is using the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

What can I do with Azure RBAC?

Here are some examples of what you can do with Azure RBAC:

  • Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
  • Allow a DBA group to manage SQL databases in a subscription
  • Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
  • Allow an application to access all resources in a resource group

Full Section is covered by Microsoft

More topics on Implement Azure security:

Implement secure cloud solutions

Microsoft Azure AZ-204 exam topics:

If you have covered the current topics in Connect to and consume Azure services and third-party services then you can have a look at the other topic areas:

View full documentation Microsoft Azure: AZ-204 exam content from Microsoft


Leave a Reply

Your email address will not be published. Required fields are marked *