BLOG

Questions Answered: Are you properly using JWTs?

You had questions, and we’ve got answers!

Thank you for all the questions submitted on our “Are you properly using JWTs?” webinar. Below are all the answers to the questions that were asked. If you’d like more information please feel free to contact us.

 

[xyz-ihs snippet=”Jwt-webinar”]

 

 

Is it considered safe if the JWT token is validated within the Asp.Net Core itself with every request. Like when it’s setup within the construct of Startup.cs? And every single controller action is marked with the [Authorize] attribute?

Yes, definitely, as long as you defined properly the JWTBearerOptions that will be used by the app.UseJwtBearerAuthentication() in the Startup call.Ā 

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.Ā 

Please have a look at https://devblogs.microsoft.com/aspnet/jwt-validation-and-authorization-in-asp-net-core/ for more details.Ā 

 

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!)

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).Ā 

WHAT is making the request (the Client in OAuth) is not in the JWT.

 

Is it a good idea to expose invalid parts of the jwt? For example I could expose that the issuer is invalid.

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.

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’ll be able to correlate with what has been logged.

 

Is it worth it to use 384 or 512 over 256?

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:

  • Processor is 64bits and not 32
  • Data to be hashed is big

In short SHA-512 for instance has ¼ more hashing rounds than SHA-256 but processes twice more data in each round (on 64 bits architecture).

So in the end, if you are on 64 bits architecture and if the data that must be hashed is bigger than 511 bits then yes, it’s worth using SHA-512

 

Is it better if I use Oauth2 to send the token to the client and JWT to send the info to my microservices?

I guess you mean ā€œhaving the external clients use OAuth2 OPAQUE access tokens, exchanged at an API Gateway/Firewall level against OAuth2 JWT access tokens before being sent to internal microservicesā€. Yes, definitely, it’s what we called the ā€œPhantom Tokenā€ in our presentation. As a rule of thumb it’s always good to avoid having data exposed in a network zone where you don’t need t!

 

Try our security audit for free. If you want to see the whole platform in action, request a demo now!

Latest Resources

WEBINAR

Why API Security Cannot Wait Until Production

EMA Associates’ recent survey of technology and business leaders in North America revealed that 32% of firms admitted to only implementing API security standards in their production environment. Join industry experts from EMA Associates and 42Crunch as they explore why business cannot let API Security to be an afterthought.

NEWS

42Crunch Announces Next Generation of API Security Testing Services at GartnerĀ® Security & Risk Management Summit 2023

By Hugh Carroll | June 5, 2023

42Crunch announces the latest set of API security testing and threat protection capabilities:
Support for scenarios testing
Automatic authorization testing to detect API 1 and API 5
Automatic authentication testing to detect API 2 issues

DataSheet

Datasheet Cover Images P1-02

Product Datasheet Addressing API Security Challenges

APIs are the core building block of every enterprise’s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developers’ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

WEBINAR

Why API Security Cannot Wait Until Production

EMA Associates’ recent survey of technology and business leaders in North America revealed that 32% of firms admitted to only implementing API security standards in their production environment. Join industry experts from EMA Associates and 42Crunch as they explore why business cannot let API Security to be an afterthought.

NEWS

42Crunch Announces Next Generation of API Security Testing Services at GartnerĀ® Security & Risk Management Summit 2023

By Hugh Carroll | June 5, 2023

42Crunch announces the latest set of API security testing and threat protection capabilities:
Support for scenarios testing
Automatic authorization testing to detect API 1 and API 5
Automatic authentication testing to detect API 2 issues

DataSheet

Datasheet Cover Images P1-02

Product Datasheet Addressing API Security Challenges

APIs are the core building block of every enterprise’s digital strategy, yet they are also the number one attack surface for hackers. 42Crunch makes developers’ and security practitioners' lives easier by protecting APIs, with a platform that automates security into the API development pipeline and gives full oversight of security policy enforcement at every stage of the API lifecycle.

Ready to Learn More?

Developer-first solution for delivering API security as code.