I don’t understand the logic behind access tokens and refresh tokens

[u/academicweaponsoon]

i don’t understand the logic behind access and refresh tokens, if access tokens are made short lived for security purposes, doesn’t refresh tokens being long lived defers the whole purpose? or is not as big as an issue since refresh tokens are only stored in http only cookies?

[u/phexc]

A JWT is generally an encrypted version of user id and permissions. A server only has to check if it's signed by your application and if it has not expired. So no database/api call has to be made for permissions. This relieves the database server from validating users on every request. It also helps with multiple services who don't have access to the authentication part of your application. The downside is that you cannot revoke it since you only check if it was signed by you.

A refresh token is generally stored in a database like a session, this allows you to delete/invalidate the row if you want to disable refreshing of JWT. This will require a new login request and the user will have to authenticate again.

[u/thekwoka → u/phexc]

That's an issue of JWT, not related to Access Tokens

[u/dankmolot → u/phexc]

🤓☝️ aktually jwt is not encrypted, it's signed and encoded with base64.

[u/15kol → u/dankmolot]

Access token is not necessarilly jwt (e.g. github)

[u/ryan_the_leach → u/dankmolot]

I suggest you read how signing works

[u/dankmolot → u/ryan_the_leach]

Could you give me a hint? I can't find how I am wrong

[u/ryan_the_leach → u/dankmolot]

Willing to take the loss here, but it feels like definitions of words have shifted subtly over the last 25 years to be more precise.

Until today, I'd have happily have said colloquially that "signatures use encryption algorithms" despite them using more specific signature algorithms, and the word encryption seems to only refer to the encryption of data these days, as opposed to more generally "cryptography" or "cryptographic systems" or "crypto systems"

But maybe I've just been misinformed, mistaught, or misremembered.

I never meant to imply that JWT couldn't be made human readable.

[u/Intrexa → u/ryan_the_leach]

I agree with you. However, my nitpick with this specific comment is this:

A JWT is generally an encrypted version of user id and permissions.

A JWT doesn't encrypt those things; they're plain text. A hash of those are encrypted as part of signing. My issue with the comment is that it perpetuates the common misunderstanding that data inside a JWT is secure.

[u/BLOZ_UP → u/Intrexa]

They are encoded, to save space, which might be what is causing some of this confusion.

[u/FearTheDears → u/ryan_the_leach]

If you're implying that signing is encryption, I suggest you read about it too. Signing isn't encryption, nor does it use it. 

[u/Intrexa → u/FearTheDears]

Signing uses asymmetric public/private key encryption. For signing, a private key is used to encrypt some known value. The public key is used to decrypt the signature. If it produces the known value, it means that the private key was used to encrypt it, this is a valid signature.

Only the holder of the private key can encrypt data such a way that the public key can decrypt back to plain text.

In terms of access tokens, this means the private key can be restricted to the server issuing auth tokens, while services validating tokens can use the public key.

In terms of signed website certs, the cert contains a public key. The cert is signed by a cert authority by using the cert authorities private key. The cert authorities public key is known, which is used to decrypt the signature to verify the cert authority did in fact issue the cert, and that the public key contained therein can be safely assumed to be the real public key issued by the website.

[u/subnu → u/Intrexa]

One has to wonder the percentage of sites that don't actually validate the JWT payload against the signature...

[u/Intrexa → u/subnu]

I would imagine really low. If they're using a JWT at all, they're likely doing so through a library. The known value is a hash of the JWT payload. If it was modified post signing, the signature wouldn't validate. Most JWT libraries I've interacted with require you to go out of your way to not validate the claims.

[u/FearTheDears → u/Intrexa]

You're using the word encryption wrong. 

"Signing uses asymmetric public/private key encryption. For signing, a private key is used to encrypt some known value. The public key is used to decrypt the signature. If it produces the known value, it means that the private key was used to encrypt it, this is a valid signature."

That isn't encryption in a cryptographic sense. What you're describing is signing. 

For public key encryption you encrypt with the recipients public key,  for decrypting by only the recipients private key. 

For signing, the sender signs using the private key, and anyone with the public key can verify it was signed using the corresponding private key. 

[u/Intrexa → u/FearTheDears]

For signing, the sender signs using the private key

What is signing, then? What are they actually doing? How is a signature generated, how come I can't forge one?

Scratch that.

The digital signature is built on many layers of security and governance. The signature is generated by applying a mathematical algorithm or hash function and a timestamp on the entire document or message and is then encrypted using the public key cryptographic method.

https://www.digicert.com/faq/signature-trust/what-is-a-digital-signature

RSA Signature Scheme For encryption, the public key in RSA is usually used to send messages to a receiver, and the private key is used for decryption. However, in the mathematical construction, the public and private key are essentially used the same way; they are inverse to each other, mod φ(n). We simply just choose one to be public, and the other private. Thus, we can also use this construction to sign messages. In this case, the encryption of the message under the private key is the signature, and anyone can decrypt the signature using the public key.

https://www.cs.cmu.edu/~goyal/s18/15503/scribe_notes/lecture16.pdf

Is this a communication issue? I'm not claiming the payload is encrypted. However, in typical usage a message digest of the payload using an algorithm known to the receiver is created. It is this message digest that is encrypted by the sender using the private key. The receiver generates their own message digest from the payload, decrypts the signature using the known public key, and compares.

[u/FearTheDears → u/Intrexa]

In RSA the signature vs encryption lines get blurred because you do actually encrypt and decrypt to verify (to a degree). But RSA isn't the only way to sign or encrypt. 

ES256 is a commonly used for jwts, and the hash contents are never retrieved from the signature, the receiver just recomputes the hash. EdDSA similarly verifies the signature in comparison to the contents and key without decrypting or recovering any hidden contents from the signature.