Wow, it's been quiet here... Enough with the intro ;) and onto the subject, which I find interesting and worthy of writing about...
Consider this scenario, which I think makes a lot of practical sense: a web single-page application (SPA) authenticates users against Azure AD using OpenID Connect implicit grant flow. Then some of the SPA's client-side components make queries to Graph API, while others hit its own server-side Web API.
What follows is highlights from my experience implementing this scenario. These are the packages I was using:
When validating tokens coming down from client components of the application, I used code similar to the one shown below, inside of ConfigureServices method:
where 11111111-1111-1111-1111-111111111111 is the tenant Id, and 22222222-2222-2222-2222-222222222222 is the client Id of application registration.
One of motivations for this post was the issue I kept getting with this authentication logic. I originally also had an extra property setting on TokenValidationParameters object:
The above line assigns a public key encoded as X.509 certificate chain to be used later to decode a signature applied to the token by the Azure AD. Check out the always-excellent insights from Andrew Connell, where he explains the need for the key-based signature checks when validating tokens and a mechanism to obtain the public key (the "cert" in the line of code above).
My logic was however failing with the error IDX10511 "Signature validation failed. Keys tried...", and my research into nuances of RSA algorithm implementation in ASP.NET and JSON Web Token encoding was fruitless until I have found this thread on GitHub, and this related thread.
It turned out that my signature validation was fine, although the line above was not needed, because the library I rely on for token validation, the Microsoft.IdentityModel.Tokens, takes care of it automatically by making a call to obtain the Azure JSON Web Key Set, and deserializing response to .NET public keys used for signature checking.
The actual wrong part had to do with my usage of access tokens: an access token obtained for a Microsoft Graph API resource happens to fail signature validation when used against a different resource (ASP.NET custom Web API in my case). This fact and that ASP.NET error message here could be improved is covered in detail in the above GitHub threads.
What I had originally, which I refer to as "naive" configuration, is shown on figure below.
On this image, I have an Azure app registration for my web application, requesting some graph permission scopes. Then during execution I acquire token on the client (1), use it when sending requests to Graph API (2), but fail to do the same against my ASP.NET Web API (3), which results in IDX10511 error.
What is interesting here, is that:
The figure below shows an improved design:
This time we treat server-side Web API as a separate application as far as Azure AD is concerned. We do have to make our SPA application acquire access token twice as shown in calls (1) and (3), doing it so for each audience: once for Graph, and second time - for our own API. Then both calls to Graph (2) and to our own API (4) succeed.
Also, this design is fitting well with the OAuth paradigm. In fact, by the time we decide to augment our Web API and start making on-behalf-of calls from within it, we have already implemented its "first leg".
Lastly, a couple notes about the MSAL Angular configuration. Here is mine:
MSAL will automatically acquire access token right after an id token is acquired after calling MsalService.loginPopup() with no scopes passed in as arguments. Commenting out or removing the consentScopes config option results in MSAL defaulting to using apps's client Id as an audience and returning a somewhat useless access token with no scopes in it.
I did this as I wanted to explicitly request separate access tokens for Graph and for my Web API. The way to do it is through passing scopes corresponding to an application to a call to MsalService.acquireTokenSilent(scopes). I am now thinking of changing it to pass the scopes of the Graph API initially, so that my first access token is useful. For the second one I have no choice but to call the MsalService.acquireTokenSilent(myWebApi_AppScopes)again.
Consider this scenario, which I think makes a lot of practical sense: a web single-page application (SPA) authenticates users against Azure AD using OpenID Connect implicit grant flow. Then some of the SPA's client-side components make queries to Graph API, while others hit its own server-side Web API.
What follows is highlights from my experience implementing this scenario. These are the packages I was using:
- ASP.NET Core 3.0 preview 5
- Microsoft.IdentityModel.Tokens v5.3.0
- Angular v7.2.5
- MSAL for Angular v0.1.2
- MSAL for JS v0.2.1
When validating tokens coming down from client components of the application, I used code similar to the one shown below, inside of ConfigureServices method:
// Example of using Azure AD OpenID Connect bearer authentication. services.AddAuthentication(sharedOptions => { sharedOptions.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; }).AddJwtBearer(options => { options.Authority = "https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111"; options.TokenValidationParameters = new TokenValidationParameters { ValidIssuer = "https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111/v2.0", ValidAudiences = new string ["22222222-2222-2222-2222-222222222222"] }; });
where 11111111-1111-1111-1111-111111111111 is the tenant Id, and 22222222-2222-2222-2222-222222222222 is the client Id of application registration.
One of motivations for this post was the issue I kept getting with this authentication logic. I originally also had an extra property setting on TokenValidationParameters object:
IssuerSigningKey = new X509SecurityKey(cert)
The above line assigns a public key encoded as X.509 certificate chain to be used later to decode a signature applied to the token by the Azure AD. Check out the always-excellent insights from Andrew Connell, where he explains the need for the key-based signature checks when validating tokens and a mechanism to obtain the public key (the "cert" in the line of code above).
My logic was however failing with the error IDX10511 "Signature validation failed. Keys tried...", and my research into nuances of RSA algorithm implementation in ASP.NET and JSON Web Token encoding was fruitless until I have found this thread on GitHub, and this related thread.
It turned out that my signature validation was fine, although the line above was not needed, because the library I rely on for token validation, the Microsoft.IdentityModel.Tokens, takes care of it automatically by making a call to obtain the Azure JSON Web Key Set, and deserializing response to .NET public keys used for signature checking.
The actual wrong part had to do with my usage of access tokens: an access token obtained for a Microsoft Graph API resource happens to fail signature validation when used against a different resource (ASP.NET custom Web API in my case). This fact and that ASP.NET error message here could be improved is covered in detail in the above GitHub threads.
What I had originally, which I refer to as "naive" configuration, is shown on figure below.
On this image, I have an Azure app registration for my web application, requesting some graph permission scopes. Then during execution I acquire token on the client (1), use it when sending requests to Graph API (2), but fail to do the same against my ASP.NET Web API (3), which results in IDX10511 error.
What is interesting here, is that:
- This setup kind of makes sense: I have an app, it is registered, and it wants to use access token it gets from Azure to let its own API "know" that a user has logged in.
- The problem can be fixed by sending an ID token instead of access token in step (3). OpenID Connect protocol grants ID token upon login, which signifies authentication event, while access token signifies authorization event. ID token's signature is validated without errors, and ASP.NET creates a claims identity for the signed in user.
What is not good about this design, is that the ID token is not meant to be used in this way. While one can choose to deviate from protocol's concept, it is not wise to do so without a compelling reason, since all tooling and third party libraries won't do the same.
Specifically, here are the problems I could identify with the above design:
- OpenID Connect, and OAuth 2.0 by extension use different grant flows depending on types of clients used. For a web browser, it is Implicit Grant, then for a server-side client it is one of other flows, depending on a scenario. We are in essence trying to use a token issued to one audience, when calling another audience. In my example, the Angular SPA and Web API are on the same domain. If they were hosted on different domains, this issue would have been more obvious.
- Microsoft uses an OAuth 2.0 extension, and on-behalf-of flow (aka OBO flow), which will be useful in scenarios when we decide to have our ASP.NET Web API enhanced by having it also access Graph API or another Microsoft cloud API. The current setup is not going to work with the OBO flow.
The figure below shows an improved design:
This time we treat server-side Web API as a separate application as far as Azure AD is concerned. We do have to make our SPA application acquire access token twice as shown in calls (1) and (3), doing it so for each audience: once for Graph, and second time - for our own API. Then both calls to Graph (2) and to our own API (4) succeed.
Also, this design is fitting well with the OAuth paradigm. In fact, by the time we decide to augment our Web API and start making on-behalf-of calls from within it, we have already implemented its "first leg".
Lastly, a couple notes about the MSAL Angular configuration. Here is mine:
MsalModule.forRoot({
clientID: environment.azureRegistration.clientId,
authority: environment.azureRegistration.authority,
validateAuthority: true,
redirectUri: environment.azureRegistration.redirectUrl,
cacheLocation: 'localStorage',
postLogoutRedirectUri: environment.azureRegistration.postLogoutRedirectUrl,
navigateToLoginRequestUrl: true,
popUp: false,
// consentScopes: GRAPH_SCOPES,
unprotectedResources: ['https://www.microsoft.com/en-us/'],
protectedResourceMap: PROTECTED_RESOURCE_MAP,
logger: loggerCallback,
correlationId: '1234',
level: LogLevel.Verbose,
piiLoggingEnabled: true
}),
MSAL will automatically acquire access token right after an id token is acquired after calling MsalService.loginPopup() with no scopes passed in as arguments. Commenting out or removing the consentScopes config option results in MSAL defaulting to using apps's client Id as an audience and returning a somewhat useless access token with no scopes in it.
I did this as I wanted to explicitly request separate access tokens for Graph and for my Web API. The way to do it is through passing scopes corresponding to an application to a call to MsalService.acquireTokenSilent(scopes). I am now thinking of changing it to pass the scopes of the Graph API initially, so that my first access token is useful. For the second one I have no choice but to call the MsalService.acquireTokenSilent(myWebApi_AppScopes)again.
No comments:
Post a Comment