Before you start with this post it would be helpful if you have already set up postman and retrieved a bearer token and an open id token from AAD based in the previous post https://www.jstack.io/post/microsoft-aad-oauth2-0-postman-collection
Also it would be very helpful if the reader has a basic understanding of the different types of tokens in OAUTH2.0 as described in this post:
https://www.jstack.io/post/oauth2-0-in-a-nutshell. in this blog.
Lets jump now and have a look at the structure of the bearer tokens issued by Azure AD.
Tokens can be of two flavors:
Opaque tokens: In this case the token is a normal string that acts as an identifier and carries no information. The issuer of the token is the same party that validates the token and knows more about the token. All API requests bearing the token will go through the token validator on the authorization service side.There is no need or desire to allow the holder of the token to examine the claims within the token. As for each request the authorization server has to verify the token, this gives the possibility for the tokens to be be invalidated centrally in the case of the bearer tokens.
JSON Web Tokens(JWT): Are mainly used when federation is desired. For example, if you can use Azure AD as the token issuer, and Apigee Edge as the token validator. With JWT, an app can authenticate to Azure AD, receive a token, and then present that token to Apigee Edge to be verified. (Same works with Google Sign-In. Or Paypal. Or Salesforce.com. etc). This opens doors for async support also. For example, you want the client to send in a request, and then store that request somewhere, to be acted on by a separate system "later". That separate system will not have a synchronous connection to the client, and it may not have a direct connection to a central token dispensary. a JWT can be read by the asynchronous processing system to determine whether the work item can and should be fulfilled at that later time. This is, in a way, related to the Federation idea above. Be careful here, though: JWT expire. If the queue holding the work item does not get processed within the lifetime of the JWT, then the claims should no longer be trusted.
Below is a bearer token issued by AAD:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IjN0Z3huQzlrVzFMMWR6clloNFNUYmEwV0tpNlhUTmEzVGhiMHFtVlllcDgiLCJhbGciOiJSUzI1NiIsIng1dCI6InBpVmxsb1FEU01LeGgxbTJ5Z3FHU1ZkZ0ZwQSIsImtpZCI6InBpVmxsb1FEU01LeGgxbTJ5Z3FHU1ZkZ0ZwQSJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9kZDZiMDI1MS0yNGFmLTQwYTQtOTZkMi04YTc0OGMyNTU3YjIvIiwiaWF0IjoxNTc3NzEwODI3LCJuYmYiOjE1Nzc3MTA4MjcsImV4cCI6MTU3NzcxNDcyNywiYWNjdCI6MCwiYWNyIjoiMSIsImFpbyI6IkFVUUF1LzhOQUFBQS9MOVdCWDFseHBBSTh4MkJKeXovN0E4U2NNWm8zSmprTUhDOTdzeFY0Vk1reTJza095Z2V2OStURjErdERNSG9mMlNWRndlaVhDVzRVRU5sbkxBWktnPT0iLCJhbHRzZWNpZCI6IjE6bGl2ZS5jb206MDAwMzdGRkUyNkY4M0Q5MyIsImFtciI6WyJwd2QiXSwiYXBwX2Rpc3BsYXluYW1lIjoicG9zdG1hbiIsImFwcGlkIjoiMzQzOWFjZjYtMWNhOS00YmFiLTgwNDktZjlhNjBmMWI1YTU2IiwiYXBwaWRhY3IiOiIxIiwiZW1haWwiOiJnam9sZWthZUBnbWFpbC5jb20iLCJmYW1pbHlfbmFtZSI6Imdqb2xla2EiLCJnaXZlbl9uYW1lIjoiZWRyaW4iLCJpZHAiOiJsaXZlLmNvbSIsImlwYWRkciI6IjE2NS4yMjUuMTkyLjE5OSIsIm5hbWUiOiJlZHJpbiBnam9sZWthIiwib2lkIjoiNjQwZmNmMDEtMzczMi00Y2Q4LWFhMjgtN2RkOWQ2ZDQ5N2E1IiwicGxhdGYiOiIzIiwicHVpZCI6IjEwMDMyMDAwODM4Rjg2RDMiLCJzY3AiOiJEaXJlY3RvcnkuUmVhZC5BbGwgVXNlci5SZWFkIHByb2ZpbGUgb3BlbmlkIGVtYWlsIiwic3ViIjoiSlRwaXI1M1dxQUYyYzAxSWR3RHRiNDJYYTdSMjJYUEI1TFN5YVNaVkZqdyIsInRpZCI6ImRkNmIwMjUxLTI0YWYtNDBhNC05NmQyLThhNzQ4YzI1NTdiMiIsInVuaXF1ZV9uYW1lIjoibGl2ZS5jb20jZ2pvbGVrYWVAZ21haWwuY29tIiwidXRpIjoiT2J5d21fdUxja201bHhDendQZzZBQSIsInZlciI6IjEuMCIsIndpZHMiOlsiNjJlOTAzOTQtNjlmNS00MjM3LTkxOTAtMDEyMTc3MTQ1ZTEwIl0sInhtc19zdCI6eyJzdWIiOiIzdUV5ZmVjVWQ5QlphdXEtNDc5MUkwUVg0bFZ5OVJxR0xyTHBxMzlCdGJnIn0sInhtc190Y2R0IjoxNTcyOTQ3NTgxfQ.iaJZX3eJkL9L16evw-MAU5qJaeAT1vOCUjq57Szpj1rH7J2gxC_mTVhcnYMmDBAPyIq3sB-u34FZL5okfn7AEAYfBKZ8GcdHLmH7eT7HAU0n96d4DdHnNcFJ-Gm4D2AiNLL9scVp9eTnfNwmxDpo5xxkwmxVibzizYsOZ1nkoVfbeBLp-hn51jmhb1Fr503DdWjS7bcbWWZi3r0ST9G6gyJQOazkmw0lksEMmc8oAwd57cv6dhP_wdTsl5i5X3w_Z4Fo1PgoLLOosu9dx0Pda6GUaBId-CaQkI7PdJUYGKAq2h6PfLRtO6pO21AguM4KJUtfi94b4bf4wAMPvOGP3A
If we look more carefully we can realize that this is a base64 encoded string. In order to read the information that is included within this bearer token we need to decode this string.
For this purpose we can use the following website: www.jwt.io
After decoding this token we can see that this is a JWT and NOT an opaque token:
Some important claims:
typ : Indicates that the token is a JWT.
alg : Indicates the algorithm that was used to sign the token, for example, "RS256"
kid : Specifies the thumbprint for the public key that's used to sign this token.
aud: Identifies the intended recipient of the token. In id tokens, the audience is your app's Application ID, assigned to your app in the Azure portal. Your app should validate this value and reject the token if the value does not match.
exp : The "exp" (expiration time) claim identifies the expiration time on or after which the JWT must not be accepted for processing.
scp : The set of scopes exposed by your application for which the client application has requested (and received) consent. Your app should verify that these scopes are valid ones exposed by your app, and make authorization decisions based on the value of these scopes. Only included for user tokens.
JWTs are split into three pieces:
Header - Provides information about how to validate the token including information about the type of token and how it was signed.
Payload - Contains all of the important data about the user or app that is attempting to call your service.
Signature - Is the raw material used to validate the token.
Below are presented the actors involved in the OAUTH2.0 flow:
Resource Owner: Edrin, the writer of this tutorial
Resource Server: Microsoft graph API where the user info API is running(or perhaps your microservice/monolithic app in a different case)- Verifies the Token.
Client: The postman application(or perhaps a SPA in a different usecase)- Requests a Token and propagates the token to the Resource Server.
Authorization Server: Azure Active Directory - Issues the Token
This bearer token must be sent into the authorization header of the API request when the client calls it. In this case the API service, Microsoft graph MUST validate this token.
More information about Identity Tokens issued by AAD in the following post:
More information about Bearer Token validations issued by AAD in the following post:
Comments