The reason behind writing of this blog is to share my view on how the traditional authentication/authorization can be modernized. Gone are the days of monolithic apps which shared a common security portal or user repository. With the microservices architecture it will be grossly ineffective to have a security firewall at each service level in the microservices architecture and very inefficient to have it tied down to each service. Rather, it should be decoupled from services. The whole rationale behind the microservices architecture is to easily adapt to the CICD pipeline and innovate and update applications at faster pace. Decoupling the services gives greater flexibility to achieve this freedom.
So the question of decoupling or isolating the security however providing a federated way of handling it will possibly be the solution. With Azure AD and its backbone built on similar design principles it can act as a solution. What I am going to discuss next may become a necessity to include OpenID connect and OAuth in the upcoming applications or newly built services going forward. As an organization if you already have an investment made in Azure AD why not leverage on the same to integrate your apps to delegate the authentication with?
These are the five primary application scenarios supported by Azure AD:
- Web Browser to Web Application: A user needs to sign in to a web application that is secured by Azure AD.
- Single Page Application (SPA): A user needs to sign in to a single page application that is secured by Azure AD.
- Native Application to Web API: A native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD.
- Web Application to Web API: A web application needs to get resources from a web API secured by Azure AD.
- Daemon or Server Application to Web API: A daemon application or a server application with no web user interface needs to get resources from a web API secured by Azure AD.
More references here –> https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios#application-types-and-scenarios
How does Azure AD achieve it? Enter OAuth.
OAuth is NOT for authentication, authorization or federation. It is a scalable delegation protocol.
· OAuth is open standard for access delegation.
· OAuth provides to clients a “secure delegated access” to server resources on behalf of a resource owner.
· OAuth2 is more of a framework than a defined protocol.
· OAuth has 4 actors; Resource owners (RO); Clients (typically apps/users browser); Authorization server (AS) and Resource Server (RS).
· In OAuth Client knows nothing about the user. All it has is an access token.
A typical OAuth flow would be something like below. Steps required to get Access Token. (Credit to this blog for the steps below.)
- The Client requests access to the Resource Server by calling the Authorization Server.
- The Authorization Server redirects to allow the user to authenticate, which is usually performed within a browser. This is essentially signing into an authorization server, not the app.
- The Authorization Server then validates the user credentials and provides an Access Token to client, which can be use to call the Resource Server
- The Client then sends the Token to the Resource Server
- The Resource Server asks the Authorization Server if the token is valid.
- The Authorization Server validates the Token, returning relevant information to the Resource Server i.e. time till token expiration, who the token belongs too.
- The Resource Server then provides data to the Client. In our case, the requested emails are unbarred and delivered to the client.
The shortcoming of OAuth is that the Client knows nothing about the user. So for example, if you use OneDrive For Business and share a document with someone else or someone else shares a document with you, your OneDrive client will be able to access the OneDrive service but it wont be able to validate the access levels. So how does it show you the information that has been shard with you? OAuth still knows nothing about you as the user. Enter OpenID Connect.
Open ID Connect works on extending OAuth (Access tokens) with ID Tokens.
OpenID Connect goes one step further of OAuth where it leverages access token and id token. This provides an identity layer. A layer that provides
WHO is the user that got authenticated.
WHERE was the user authenticated.
WHEN was the user authenticated.
HOW was the user authenticated.
WHAT attributes the user can give to the client.
WHY is he providing them.
Facebook extends OAuth with proprietary “Signed Request” which is specific to Identity provider (itself) and hence limited by choice. In contrast, OpenID Connect works with multiple identity providers and uses the IEFT JSON web signature. JSON (JWT) web tokens carry information about the user such as
- The issuer
- The subject or authenticated uses (typically the Resource Owner)
- How the user authenticated and when
- Who the token is intended for (i.e., the audience)
Here is a sample JSON Web Token or JWT (pronounced as jot)
Logon to Microsoft provided https://oauthplay.azurewebsites.net
Select the Microsoft Sandbox account for testing. Just hover around the sandbox account to get the password for it.
Once the user is Authenticated an Authorization code is received which is used to get refresh token; access token and identity token.
Look for identity token. Copy the value and go to https://jwt.io to decode this encoded token.
Observe the values of this token. Now this token can be used to in step 3 of https://oauthplay.azurewebsites.net
Using AzureAD which relies on the acknowledged principles of OpenID connect and OAuth it is possible to modernize the applications to use or leverage upon.
References:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-tokens# ID tokens
https://tools.ietf.org/html/rfc6749#section-4.1
http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation
https://thehackernews.com/2013/10/vulnerability-in-facebook-app-allows.html
https://easyauth.azurewebsites.net/
This article was first published on www.procloudguru.com by Alpesh but the website no more exist, hence re-publishing the content.