Implement user authentication and authorization

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

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

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.

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

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 https://login.microsoftonline.com/common for all directories in Azure AD, while a tenant-specific endpoint might be https://login.microsoftonline.com/contoso.onmicrosoft.com. 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

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

Implement IaaS solutions

Create Azure App Service Web Apps

Implement Azure functions

Develop solutions that use Cosmos DB storage

Develop solutions that use blob storage

Integrate caching and content delivery within solutions

Instrument solutions to support monitoring and logging

Develop an App Service Logic App

Implement API Management

Develop message-based solutions

Develop event-based solutions