WebAPI validate token for different cliend Ids

Help
,
1

We need to validate a JWT in WebAPI application, that should support requests comming from different clients (having different ClientIds)

As per Auth0 documentation I have this snippet at Startup.Configuration

(doc url: Auth0 ASP.NET Web API (OWIN) SDK Quickstarts: Authorization)

appBuilder.UseActiveDirectoryFederationServicesBearerAuthentication(
     new ActiveDirectoryFederationServicesBearerAuthenticationOptions {
             TokenValidationParameters = new TokenValidationParameters { 
                  ValidAudience = audience,
                  ValidIssuer = issuer,
                  IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => parameters.IssuerSigningTokens.FirstOrDefault()?.SecurityKeys?.FirstOrDefault()},
                  MetadataEndpoint = $"{issuer.TrimEnd('/')}/wsfed/{audience}/FederationMetadata/2007-06/FederationMetadata.xml"
      });

This is working, but, obviusly for only one ClientID.

Any idea on how (if it is possible) set a different ClientId per Request. (We know the clientId on each request).

2

Can you update your question with a link to the documentation in question and mention any Auth0 libraries (including versions) that you’re using?

3

Updated with documentation url.
Disclaimer: Very new to auth 0 we are currently PoCing this. Should we use a different apporach.

The backend is a Owin WebApi. And we only want to validate the JWT and retrieve some user metadadata. For different applications that consume this api.

4

The approach described at this time on that quickstart is not the latest available. The use of the token issued to the client application itself (the audience of the token is the client identifier) in a back-end API has the side-effect of imposing an high degree of coupling between the client application and the API itself. This could work for API’s that are implemented to serve the need of a single application, but for API’s that go beyond a single client does not work.

The recommended approach is to treat the API as an independent entity so that client application A can authenticate the user, receive an ID token representing the authenticated user, but at the same time receive an access token that can be used to call into the API.

With this approach introducing a client application B can follow the exact same approach where the application also receives an ID token and access token. The ID tokens will have audience specific to each client application because they are meant for them to interpret and validate, however, in both cases the issued access token will have an audience that represent the API identifier itself.

This resolves the problem of multiple audiences because now the API validates tokens that have an audience representing the API itself and mostly does not care about which client application is calling. It only requires that the access token is valid (the decision of which client application can request access tokens for the API would be performed elsewhere).

I don’t think we have a .NET quickstart updated with this approach, but you can read more about the overall approach at: Authentication and Authorization Flows

At a very high-level it’s almost the same as before, you configure the API to receive tokens, but use the identifier and signing configuration of the API itself and then the client application sends the access token to the API instead of the ID token (in order to obtain a proper access token, you would additionally include in the authentication request that you wanted to call that specific API).

5

Thanks for your response… making more sense now. I started to try this apporach… so if I undesrtand this right…

I need to create my API under the API section… (different than a SPA client for example)
If so,when I want to validate that access token, do I need that API clientId… or I can just use the issuer and the audience to validate that?

Also is it possible to include user metadata information in the access token?

6

When configuring the API under the respective section, you’ll configure an API identifier (similar to a client application identifier, but you provide it manually) and you’ll use that identifier as the audience for token validation. You can include additional custom information in the issued access token; see: OpenID Connect Scopes