3

I am tasked with implementing authentication and authorization in a distributed environment, so I plan to use JWT.

I get how authorization works with JWT - if the token is not expired, and the signature, as checked server-side, matches the header + payload, the user is authorized to a resource (I plan on using symmetric encryption).

But does the fact that a valid, non-expired JWT is included in the request necessarily mean that the user passed the authentication process, if we assume client-server communication is done over TLS? Or are there additional checks to be performed in order to trust the authenticity of the user?

In all the resources I went through, this seems to be implied, but nowhere is it stated explicitly.

Improve this question
7
  • 2
    "I plan on using symmetric encryption" Why? TLS uses symmetric encryption after the requisite handshakes are complete. Rolling your own security is like the 'House of the Rising Sun': it's been the ruin of many a poor boy. Commented Oct 17 at 21:07
  • @JimmyJames because the decision is made above me, it's sadly that simple. I might sway it towards a 3rd party provider, this question is a preparation for the worst-case. Commented Oct 20 at 8:32
  • 1
    @JimmyJames, some goverments mandate use of national CA, making TLS with dynamic certificate verification moot and void. Others ban TLS 1.3, because destination ecryption breaks censorship. Commented Oct 20 at 8:56
  • @Basilevs You can always prune your trust to the CAs you wish to deal with. I've been working with a non-public CAs using TLS for more than a decade. Commented Oct 20 at 14:08
  • @JimmyJames not when you go to jail when some of you traffic can't be MitM decrypted (not that I know of concrete examples, but the ban on VPNs and TLS 1.3 shows clear trend). BTW, publishing VPN configuration instructions are a punishable offense now. Commented Oct 20 at 18:59

4 Answers 4

Reset to default
6

JWT is just a signed blob of data under the hood (we are not going to talk about JWTs without signature in this answer). How, when and why it was created cannot be known for sure. The only thing that can be known is that someone signed this token. And if you do a strong enough cryptography with JWT, and the signing entity kept its secrets, well, secret then you can be quite confident that it was this entity who signed the token. Note that JWT in the most general variant doesn't even have to provide any user/account information. But we are assuming it needs a secure signature.

So the rest is a matter of trust. If this entity says that this is user X, then can I trust it? In the ideal situation the answer is yes. For example if you have full control over this entity, then you can enforce those guarantees yourself.

But of course the reality is not ideal. There can be various reasons why this entity may be wrong. From simple inconsistencies (e.g. the account was deleted but the information was not propagated correctly) to serious hackers attacks.

So should the target server verify JWT claims? Well, this goes against its design. But depending on the nature of your service it might be necessary. For example if you are a bank, then maybe you need an additional layer of authentication, e.g. 2FA.

But usually you should be fine with trusting these claims. I mean, you already do that in the context of resource access. Which is the same thing actually. It's just a matter of trusting claims generated by some other server.

Bonus 1:

I plan on using symmetric encryption

I assume you mean "symmetric signature of the JWT". Don't. It is a lot harder to keep a shared secret a secret. With asymmetric encryption/signature only the signing entity needs to keep its private key secret. And public key can be known to anyone (including 3rd parties, if they wish to verify the claims, which is not possible with symmetric signature). The more servers you have the more secure it is.

Bonus 2:

if we assume client-server communication is done over TLS

It doesn't really matter (in the context of signed JWT validation). The JWT comes with its own internal cryptography anyway (or rather: I strongly discourage anyone to use it without signature). And the public/shared keys need to be known to the participating servers before any communication (with the client) starts anyway. You won't be able to forge it, regardless of whether the communication is over TLS or not. There are of course other, very important reasons to use TLS.

Improve this answer
18
  • 1
    "The JWT comes with its own internal cryptography anyway" If, signed, that is. It's worth noting that JWTs are not typically encrypted. I don't think you are claiming they are here but I think it's a common misconception that they always are. If there's sensitive information in the JWT, that could be an issue. Commented Oct 17 at 21:20
  • 2
    @JimmyJames oh, I actually didn't know they can be used without cryptographic signature. IMO that's a mistake in the design. Anyway, I've updated this piece of answer. Commented Oct 17 at 21:23
  • 1
    "JWT is just a signed blob of data under the hood ... How, when and why it was created cannot be known for sure... So the rest is a matter of trust." — the bedrock upon which cyber security rests. No matter how strong the encryption is, you need to trust the people or organization that signed the token. No trust; no security. Commented Oct 18 at 0:58
  • 2
    @dzenesiz obviously the shared secret has to be shared only by your own services. How would that be secure otherwise? Would you trust a 3rd party to hold your password? I wouldn't. But still it is less secure than a secret stored on a single service only (regardless of the number of services you have). Just because you have control over microservices, it doesn't mean you control everything. There are so many layers of attack, this shouldn't be treated lightly. Commented Oct 20 at 9:22
  • 1
    Also, as a side effect, with asymmetric cryptography you allow 3rd parties to actually validate your JWT. With symmetric key, this is impossible to do in a secure way. Any holder of a shared key is able to forge tokens. That's the reason you don't want it. Commented Oct 20 at 9:26
1

TL;DR

JWT may be a part of a properly designed authentication protocol. Alternatively it may serve only for authorization without authentication.

Ticket analogy

If you buy a movie ticket, it may advertise, depending on cinema and local laws:

  • your name
  • age
  • seat number
  • time and date of the movie session
  • internal tracking number
  • QR code
  • or none of these things

The only mandatory property of a ticket is a hard to fake feature like a watermark or a hologram, that will be checked upon entrance, identify the ticket as legitimate and let you in.

Cinema theater can choose to put as much information in it as they want. Sure, a gate attendant trusts that whatever is printed on a ticket was at one point a belief of a cashier. But that is just payload, conceptually, only ticket fake-proofing is important.

In particular, ticket owner might be a mugger and not a buyer, cashier could be wrong or compromised, gate attendant can apply any additional checks or policies. Ticket does not adress these concerns.

JWT is like a movie or a bus ticket - it grants you access to something without any identification or association with a buyer.

Paper tickets are easier to invalidate upon contact, so analogy is not exact.

Authenticantion protocol requirements

Formally a signed JWT is an integrity-protected transport channel from a trusted party to an undefined count of clients over untrusted media and nothing more. What data is being protected is an application level concern and is for protocol author to decide.

Importantly, JWT does not authenticate on its own. It just proves that presenter of the token has access to the same information as its original recepient - i.e. the presenter is either:

  • legitimate client
  • legitimate server
  • MitM
  • client's friend
  • client trojan
  • server trojan

The default contract implies:

  • server and client are not compromised
  • communications are securely encrypted
  • client does not share the token.

Only then authentication infromation, if any, delivered via the token can be trusted.

Improve this answer
-1

The first thing to understand is that you would typically only accept JWTs signed by an entity that you trust. You can't just accept any JWT signed by some unknown entity. Anyone can create a their own keys and sign a JWT that grants any permission they choose. You are putting you users and your system's security in the hands of that signing entity. Trusting a signing entity is not something to take lightly. The rest of this answer is based on the assumption that your signing entity (or entities) authenticate users before issuing JWTs.

Possession of a valid token does indicate that the token owner has authenticated at some point in the past. How long ago that might have been depends on how your authentication and authorization is configured. You don't specify in your question but generally JWT questions relate to OAuth2 and when discussing OAuth, I think it's good to make sure everyone understands that there are a number of different authorization flows that are designed for different use cases.

Without getting into the details of each of these options, a common pattern is to have a refresh token and an access token in one of these designs. The refresh token is longer lived and requires user authentication. The refresh token is then used by the user to retrieve an access token. So in that scenario, having a valid access token would be understood to mean that the user has/had a valid refresh token which essentially means they were authenticated at least as recently as the refresh token's lifetime.

Improve this answer
10
  • Consider a site that does not have authentication. Why can't it use JWT? Commented Oct 17 at 19:36
  • @Basilevs It could. Why is that relevant? Commented Oct 17 at 20:47
  • @Basilevs I'm not completely sure what your concern is here but I added some clarification. Commented Oct 17 at 21:02
  • If you think this answer is wrong, I'd love to see why. Commented Oct 17 at 21:17
  • 1
    "Possession of a valid token does indicate that the token owner has authenticated at some point in the past" this particular statement is incorrect. We can allow user to do something without establishing her identity, hence no authentication is needed. Commented Oct 17 at 21:32
-2

But does the fact that a valid, non-expired JWT is included in the request necessarily mean that the user passed the authentication process, if we assume client-server communication is done over TLS?

Yes, if the communication is over TLS, the authentication is performed over safe HTTP method (e.g. POST) and after the authentication the request includes the authorisation header with the JWT token and if that way the authentication/authorization was designed. That doesn't mean the authenticated user belongs to the person going through the authentication, there is no way to make a direct connection between some credentials and the person initiating the authentication.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.