0

We have a microservices architecture. One of the components is an Authentication & Authorization Service, which implements OAuth2 standard using encrypted JWTs. On each authentication of a user to any component, the component sends a REST to the service to get an access token. On each REST interaction of a user to any component, the component sends a REST with the user's access token to the service to authorize their right to do the interaction. I have two concerns:

  1. Components talk over SSL. OAuth2 requires JWTs to be encrypted, so we blindly follow that and encrypt them. So, encrypted token travels inside the SSL which doesn't make sense to me, but we have a requirement to follow the OAuth2. I feel like OAuth2 means that the JWTs must be encrypted in general, not independently of whether we use encrypted protocol or not (but I am not sure about that).
  2. We always ask a remote service for the rights verification, but I feel like a component could just use a public key to verify the JWT's signature and simply read the payload to find the demanded ROLE entry in there without involving the network.
Improve this question

1 Answer 1

Reset to default
1
  1. To quote RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) here:

In some deployments, including those utilizing load balancers, the TLS connection to the resource server terminates prior to the actual server that provides the resource. This could leave the token unprotected between the front-end server where the TLS connection terminates and the back-end server that provides the resource. In such deployments, sufficient measures MUST be employed to ensure confidentiality of the token between the front-end and back-end servers; encryption of the token is one such possible measure.

  1. In theory you can but this means that if someone manages to find an exploit in your token generation, a collision of the signature the JWT has which gives greater rights or something similar they will have more access to the system. By relaying this to a service which isn't editable from the outside you mitigate the risk of this happening. Of course this does mean that you have to protect the rights verification service properly since if that is compromised you're screwed either way.

To continue on point #1, there's some more information within section 5.2 which might be particularly interesting for you considering the first question. I've personally found that most RFCs are very good at declaring the reasoning behind decisions and recommendations so reading them is typically very helpful even though they might seem like dull documents at first.

Improve this answer
5
  • What do you mean by finding an exploit in my token? Isn't asymmetric encryption a normal thing everybody does? It would only be used to verify the signature, while the payload is already exposed because it's a base64 encoded. Only using the private key you can create a valid signature. Also, I found in the RFC that there is a case where we don't want the clients to see the base64, so we encrypt the token itself in addition to the TLS. By the way, thank you! :)
    – Sam
    Aug 21, 2017 at 12:12
  • @Sam I'm thinking about things such as a weak algorithm being used, someone finding out what software you use for generating the JWT and finding a bug or security breach in that software. Regarding the signature I'd recommend reading up on hash collisions which is when different input create the same hash (the signature in your case), a good starting point could be the collision attack page on Wikipedia.
    – Robzor
    Aug 21, 2017 at 12:43
  • @Sam Another reason I just thought of to not include the role in the token is that the role would be bound to the token(s). This matters when you perform changes to a user's roles. You'd need to invalidate old tokens to apply or, more importantly, remove roles.
    – Robzor
    Aug 21, 2017 at 12:45
  • Well, the bad guys would first need to bypass the TLS to even get to the signed JWT, which is already very unlikely. Also, there a jti field for token revocation purposes.
    – Sam
    Aug 21, 2017 at 13:15
  • @Sam This depends on how you store the JWT. If it's stored unencrypted in HTML5 local storage all Javascript running on the page can access it (you can try this by opening your Javascript console here on Stackoverflow and inspecting it). A cookie has similar caveats in readability, though these can be encrypted (notice how we've arrived at a JWT which is hidden from the user again). Man in the Middle attacks are far from the only attack vector to consider (for more learning you can look to Owasp and their top 10).
    – Robzor
    Aug 21, 2017 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.