Securing applications by selecting proper Authentication Flow with Microsoft Azure AD
This article is based on our approach to select the best authentication flow for integrating user authentication with Microsoft Azure AD to a separate Angular 9 frontend and a Spring boot backend application. I have thought of sharing the knowledge that we gathered as a team since we spent a considerable time on selecting the best approach for our application.
Before I proceed. I thought of sharing a fundamental concept.
OAuth 2.0 Terminology
OAuth 2.0 is an authorization framework that allows interchange and authorization policies across resources.
OAuth terminology has several interacting elements.
Resources: Protected resources, which required to be exposed in a controlled manner.
User: The resource owner who grants permission to access some portion of the resource.
Authorization Server: The authorization server evaluates policies.
The Client: The client is the app that is attempting to act on the user’s behalf or access the user’s resources.
Token: It is a string denoting a specific scope, lifetime, and other access attributes. The client uses tokens to access resources available on the server.
OpenID Connect
Is an extended development on top of OAuth targeting single sign-on use cases and sharing user profile information.
Our approach was involved in authenticating organization users. This approach is for integrating Microsoft Azure Active Directory with an Angular 9 front-end application with Spring boot backend application.
To be specific on above,
Azure AD is to develop apps for organizations and their corporate users
Azure AD B2C is to develop apps for customers, like mobile apps, online shopping platforms, etc.
We are using Azure AD since it allows user identification securely with the OAuth 2.0 and OpenID Connect protocols. which makes use of tokens. Tokens used in Azure AD are JSON web Tokens.
The following tokens are used in communication with Azure AD B2C:
ID Token
This token uses to identify users in our application. ID Tokens are signed and not encrypted. This token is securely sent in HTTP requests for communication between two components of the same application or service. Our application should validate the token.
Access Token
This token is used to access APIs and resource servers. Access tokens are signed, but they are also not encrypted.
Refresh Token
Refresh tokens are used to obtain new access and ID Tokens. Refresh token’s usage is to gain long-term access to resources on behalf of users without requiring interaction with those users. Application services save the refresh token when the access token is expired and Still, there is no guarantee that these refresh tokens are valid forever and application should manage as these tokens can be invalidated at any time.
Selecting authentication flow for a service should be selected with care as choosing the most suitable flow will minimize associated security risks.
There are several grant types available with Microsoft Authentication Library (MSAL).
Interactive Flow
This process gets token through user login from User credentials through a browser or pop-up window.
Suitable for Desktop apps and mobile apps, some CLI apps which run on desktops also use this approach.
Implicit Grant Flow
It allows a single page app to get tokens without having a backend server. This library allows to handle user sign in, maintain sessions, manage tokens in a Single Page Application.
Authorization Code Flow
Regular web apps are server-side apps where the source code is not publicly exposed. They can use the Authorization Code Flow which exchanges an Authorization Code for a token. Your app must be server-side because, during this exchange, you must also pass along your application’s Client Secret. Which must always be kept secure, and you will have to store it in your client.
In the Authorization Code Flow client-side application( front channel) never receives access token immediately, it receives authorization code(Auth code). It is an onetime code used immediately, Only useful for seconds. Credentials also not handled by the Web application.
The web application uses the Authorization Code, the Client ID, and Client secret to access the token endpoint to obtain access and refreshes tokens. Since the entire flow is handled mostly by the backchannel. The client browser never sees Access Token or Refresh Tokens.
Since this process requires real user involvement we can’t use this for microservices.
This is not suitable for Mobile apps and Single Page apps as well they are not capable of holding client secrets, which is like the password for our application in Azure AD.
Authorization Code Flow with PKCE (RFC 7636 Authorization Code Grant using Proof Key for Code Exchange)
PKCE is also a bit similar to Code flow but does not use Client secret as it is used for native mobile apps, which cannot keep the client key securely.
This flow is much more secure than using Implicit grant flow. When it generates a code challenge which is the Base64 encoded SHA256 hash of that code verifier. When you make the authorized request the application will send the code challenge and keep the code verifier secret. Assuming the authorization was successful the authorization server responds with the authorization code just as before. When the application exchanges the authorization code with the tokens it sends the code verifier in the request. The authorization server hashes and encodes the code verifier to compare against the original code challenge sent before. Since the verifier hasn’t been sent previously and they were never sent together, the server can assume the original authorized app is the one still making the requests.
Client credentials
This flow is mainly useful for applications that have no direct user interaction such as microservices. These services interact with the server to the server.
Integrated Windows Authentication
This allows applications on domains to acquire tokens silently without user UI interaction. This is only available on a domain or Azure AD with limitations.
Username/password
This not a recommended flow, yet some applications use this flow. This allows an application to log in to the user by directly handling the passwords.
To learn more about Microsoft Authentication Library provided Authentication flows please visit the below link.
To Conclude, our approach for selecting Authentication Flow was Authorization Code flow, since it had both the front channel and backchannel.
Risks associated with Native apps and Single Page Applications
Single-page apps
It cannot securely store a Client Secret because the entire source is accessible through the browser.
Native apps
Decompiling the app will reveal the Client Secret, Cannot securely store a Client Secret. which is bound to the app and is the same for all users and devices.
Why should we choose Authorization Code Flow for applications with a server backchannel?
The main downside to the Implicit grant type is that the access token is returned to the browser, rather than being returned via a trusted back channel like in the Authorization Code flow. The access token itself will be logged in the browser’s history, so most servers issue short-lived access tokens to mitigate the risk of the access token being leaked. There is no backchannel, the Implicit flow also does not return a refresh token.
I hope this article will help you to select the best approach for our application when integrating with Azure AD.
“People can like what you write, they can dislike it, they can love it, they can hate it, but it should not confuse anybody.”
Timothy Ferriss.
Further reference,
Azure AD, B2B, B2C
MSAL Flows
Authorization Code Flow
Implicit Grant Type
PKCE
Client Credentials Flow
See you in another article with implementation details …
Your claps will encourage me to write more articles in the future. If you have questions or anything to be corrected and improved please write a comment in the comments section or send me an email — chamith.chathuka@axiatadigitallabs.com
