Using JTWs in OAuth Implementation

Question

I am currently building an api for an app to communicate with. The api endpoints will be protected, so I'd like to use an OAuth flow with JWTs for security. My flow will go something like this:

• Receive and validate user credentials
• Issue an access token (JWT) and refresh token for valid credentials
• Verify integrity of access token then verify expiration
  • If expired - send a 401 and expect to receive a refresh token which will then be validated and a new access token will be issued
  • Else use user id claim to gather more context and continue on with request\

My questions:

• JWT integrity: A Compact JWT is comprised of three parts - header, payload, and signature. The signature is verified by applying the alg specified in the header section to the base64url encoded header and payload sections separated by a '.' and then base64url encoding the produced value. Does this mean it is possible to create a phony access token? A stolen access token could be unencoded, user id stolen and inserted into a very similiar, but fake, access token. This fake token is then signed as a regular JWT is. When the server receives this access token, would this token not hold its integrity?

• OAuth flow: Does this seem to be a proper flow? A user's refresh tokens will be stored in a database so they can be verified in the future (these will have a long lifetime). The access token will rely on its own integrity and the information contained within it since its lifetime is so short.

Answer 1

Does this seem to be a proper flow?

I don't see anything wrong with it. Take care with the word 'flow' though, it has specific meaning when talking about OAuth, and you're note using it in accordance with what "OAuth flow" means.

Does this mean it is possible to create a phony access token?

In order to sign a JWT, you need to know a secret. JWT supports signatures either via HMAC (which requires a simple, pre-shared secret) or with public key cryptography [1]. All oauth providers I've worked with - most notably Google and Microsoft - use public key cryptography (RSA) to create the digital signature.

So, the attack you describe depends on the attacker having access to the private key of of the institution that signed the JWT. Access to the public key isn't enough; you can use this to check whether the signature is valid, but you can't use the public key to re-sign an altered token.

If the JWT in question used simple hmac instead of public key cryptography to create the signature, then both the signer and the party that needed the secret in order to check the signature would be in a position to correctly sign an altered JWT. But in that case, if the access token was stolen, the thief still wouldn't have the secret. I only see possible danger when the person the access token is intended for willfully changes it and resigns it using the shared secret. I'm not sure what the security implications of such an attack would be, but I guess this is why the big OAuth providers use public key cryptography.

[1] https://jwt.io/introduction/

Answer 2

JWT Integrity: If you use a symmetric key to sign your token, and this key is stolen, the answer to your first question is: YES. But if you use asymmetric cryptography, you can sign the token with your private key (store this private key in a secure place) and send the token to the user (please use TLS between client and server). The signature is applied to the entire token, so if a malicious user gets the token, he can't tamper it because he doesn't know the private key used to resign the entire token.

OAuth flow: Yes.