question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Any ways not to verify scope or role claim in the jwt token

See original GitHub issue

Is your feature request related to a problem? Please describe. This library always verify scope or role whether inside a JWT token pass in Auth header, if they both not exist, it will throw exception:

IDW10201: Neither scope or roles claim was found in the bearer token.

However, we do not want to verify existence of this two claims, and didn’t find any configurations for it.

Describe the solution you’d like We want a simple config which can turn off or turn on this verification

Describe alternatives you’ve considered On way I consider is to override the token validation handler just like below:

services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
{
    Configuration.GetSection("AzureAd").Bind(options);
    var existingOnTokenValidatedHandler = options.Events.OnTokenValidated;
    options.Events.OnTokenValidated = async context =>
    {
        // await existingOnTokenValidatedHandler(context);
    };
});



However, the code above would cause the exception below:

No account or login hint was passed to the AcquireTokenSilent call

Another way I think is to config AAD to append application role claim inside the JWT token. However, this need admin consent for the AAD, which is not acceptable.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:6

github_iconTop GitHub Comments

1reaction
jmprieurcommented, Oct 28, 2020

@SLdragon : yes Access Control Lists. This is because you can secure your web API with ACLs. See control tokens without a roles claim

1reaction
jmprieurcommented, Oct 27, 2020

Yes, @SLdragon : the token validation will still happen, but the library won’t throw if your token has neither scope or roles (as this is a valid scenario if you protect your API by ACLs, or just enforce verifying roles/scopes in your controller actions/pages methods: see https://github.com/AzureAD/microsoft-identity-web/wiki/web-apis#verification-of-scopes-or-app-roles-in-the-controller-actions

Read more comments on GitHub >

github_iconTop Results From Across the Web

JWT - validate scopes and/or claims against issuer
However, it seems like a best practice should be to not only validate the issuer as being valid, but that the claims they...
Read more >
Neither scope or roles claim was found in the bearer token ...
Configure<JwtBearerOptions>(JwtBearerDefaults. AuthenticationScheme, options => { // The claim in the Jwt token where App roles are available. ...
Read more >
Protected web API: Verify scopes and app roles
NET Core validate the token. Your API needs to verify that the token used to call the API is requested with the expected...
Read more >
JWT, What the best practice with using Claim/Roles : r/dotnet
So technically, start by sending claims in the JWT token, not permissions. Then make a middleware that reads the JWT token from the...
Read more >
JSON Web Token Claims
Describe JSON web token (JWT) claims and how they are used in Auth0. ... pair where the name is always a string and...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found