{"id":7922,"date":"2020-02-03T22:03:31","date_gmt":"2020-02-03T22:03:31","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=7922"},"modified":"2022-11-23T10:32:35","modified_gmt":"2022-11-23T10:32:35","slug":"webinar-questions-jwt","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/webinar-questions-jwt\/","title":{"rendered":"Questions Answered: Are you properly using JWTs?"},"content":{"rendered":"
\n

You had questions, and we’ve got answers!<\/strong><\/h2>\n
Thank you for all the questions submitted on our “Are you properly using JWTs?<\/strong>” webinar. Below are all the answers to the questions that were asked. If you’d like more information please feel free to contact us<\/a>.<\/div>\n<\/div>\n
<\/div>\n

 <\/p>\n

[xyz-ihs snippet=”Jwt-webinar”]<\/div>\n

 <\/p>\n

 <\/p>\n

\n
Is it considered safe if the JWT token is validated within the Asp.Net Core itself with every request. Like when it\u2019s setup within the construct of Startup.cs? And every single controller action is marked with the [Authorize] attribute?
\n<\/strong><\/h5>\n

Yes, definitely, as long as you defined properly the JWTBearerOptions that will be used by the app.UseJwtBearerAuthentication() in the Startup call.\u00a0<\/span><\/p>\n

Also retrieving dynamically the cryptographic material by dereferencing it from the value of the Issuer field of the JWT can sometimes be dangerous so instead of specifying the Authority field of the JWTBearerOptions object it can be interesting to specify the Issuer value (oftenly an URL) and a local value of the key to be used in a custom TokenValidationParameter.\u00a0<\/span><\/p>\n

Please have a look at <\/span>https:\/\/devblogs.microsoft.com\/aspnet\/jwt-validation-and-authorization-in-asp-net-core\/<\/span><\/a> for more details.\u00a0<\/span><\/p>\n

 <\/p>\n

In this presentation the JWT are used as a mechanism to identify WHO is in the request, and for identifying WHAT is making the request?(WHO – The user in the request. WHAT – The thing making the request. It’s coming from Postman, an automated script or from the genuine and untampered mobile app!)
\n<\/em><\/strong><\/h5>\n

When it comes to JWT used for OAuth2.0 and OpenIDConnect scenarios the JWT is used as a mechanism identifying on behalf of WHO is made the request (sub claim) WHAT is the target entity (the aud claim: the Resource Server -RS- in OAuth terminology, the Relying Party -RP-in OIDC terminology) and WHAT has issued the JWT (iss claim, the Authorization Server -AS- in OAuth terminology and the Provider -OP- in OpenID Connect terminology).\u00a0<\/span><\/p>\n

WHAT is making the request (the Client in OAuth) is not in the JWT.<\/span><\/p>\n

 <\/p>\n

Is it a good idea to expose invalid parts of the jwt? For example I could expose that the issuer is invalid.
\n<\/strong><\/h5>\n

No, this is a bad idea, as the more details you give about why is the JWT invalid the more you give info to a potential attacker so that he can now try to brute-force this or that and in the end retrieve some info that he should not be able to retrieve.<\/span><\/p>\n

Use generic error messages to be sent back to your clients, keep detailed informations in your logs. One good way of being able to give detailed info to a client, using a back channel mechanism and after you verified that this info request is legitimate) is to give a transaction ID in the generic error message that you\u2019ll be able to correlate with what has been logged.<\/span><\/p>\n

 <\/p>\n

Is it worth it to use 384 or 512 over 256?
\n<\/strong><\/h5>\n

In terms of pure security not really, as SHA-256 is not a priori to be broken for quite a few years. BUT SHA-384 and SHA-512 are slightly better in terms of security and are faster in some cases:<\/span><\/p>\n