You had questions, and we’ve got answers!
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!
