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

Mitigate OWASP API risks through security-by-design

Learn best practices and mitigation steps for some of the OWASP API vulnerabilities through this 42Crunch API security best practice webinar
Nov 5, 2024
PST 9am | EST 12pm | GMT 5pm

NEWS

VicOne Partners with 42Crunch to Deliver Uniquely Comprehensive Security Across SDV and Connected-Vehicle Ecosystem

By Newsdesk | May 29, 2024

Collaboration pairs leaders in API and automotive cybersecurity to enable broad protectionĀ as attacks on automotive APIs climb within and among vehicle, cloud and mobileĀ  DALLAS and TOKYO, May 29, 2024ā€”VicOne, an automotive cybersecurity solutions leader, today announced a partnership with 42Crunch Ā to enhance the security of application programming […]

DataSheet

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

Mitigate OWASP API risks through security-by-design

Learn best practices and mitigation steps for some of the OWASP API vulnerabilities through this 42Crunch API security best practice webinar
Nov 5, 2024
PST 9am | EST 12pm | GMT 5pm

NEWS

VicOne Partners with 42Crunch to Deliver Uniquely Comprehensive Security Across SDV and Connected-Vehicle Ecosystem

By Newsdesk | May 29, 2024

Collaboration pairs leaders in API and automotive cybersecurity to enable broad protectionĀ as attacks on automotive APIs climb within and among vehicle, cloud and mobileĀ  DALLAS and TOKYO, May 29, 2024ā€”VicOne, an automotive cybersecurity solutions leader, today announced a partnership with 42Crunch Ā to enhance the security of application programming […]

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.