5

As far as I understand in OAuth there is a refresh token and there is an access token. The access token cannot be revoked but short-lived and on next refresh access there will be no access token if revoked. I have a simple application where I issue tokens myself and consume myself all in one application (both mobile and web, but same API), so I don't need any complex OAuth or OpenIdConnect for 3d parties. I want to use this scheme with just one token for simplicity, but I want to refresh it as well for performance reasons (not to check revocation on each call):

  1. A client provides a username and password to a special endpoint and receives a JWT back that is signed but not encrypted (that's good enough as far as I understand, user can read but not forge). I use JwtSecurityTokenHandler in .NET to issue token myself without Oauth or OpenIdConenct servers to do that. The token is signed using RSA SHA 256 with certificate that I created myself. Token is short-lived, e.g. 1 hour.
  2. All api calls are amended with Bearer authentication and I read the token on the server and verify the signature and expiration (nothing else like Audience, etc.). The server will trust this token and will not check for revocation.
  3. If the server detects that a token is expired it will return some 40x to let the client know to refresh the token. (Client can do pre-verification of expiration date itself since token is not encrypted to save some server calls).
  4. If the token is expired, the client will call refresh and pass the same token to it. The difference will be that this time the revocation status is verified (I have a simple revoke all tokens for user policy, not per token). I will check the additional timestamp of initial issue that is not changed with refreshes and verify it against that it's greater than user's timestamp which is set e.g. when a user changes password. The result is another token of the same type with the same initial timestamp and expiration time of 1 more hour. If revoked, then the user will have to relogon.

I really need to refresh only because of performance considerations, but I am wondering maybe I am missing something and there is really a security issue or maybe some other troubles with this simplified flow with only one token?

Silvaethor
  • 3
  • 3
Ilya Chernomordik
  • 2,197
  • 1
  • 21
  • 36

1 Answers1

2

If you're in control of both the client and the server and you can ensure that both tokens are always transmitted securely, there is no drawback in using the same token for both.

Normally, the refresh token is the critical token to protect, as this allows indefinite access to the application. It is also easier to control which transports this is transmitted over. However, in your case if you can apply the same security to the access token then there is no extra risk in them being the same.

Also see this answer.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • I do control both client and server and will use only https for transmission. I do not know though on the ways to store the token "securely" (or protect it in other way) it's really either local storage or session storage... – Ilya Chernomordik Jan 26 '16 at 09:11
  • It depends on your threat model and risk appetite. Typically those storage mechanisms are adequate - ensuring you transmit over HTTPS only covers the biggest risk of the token leaking. – SilverlightFox Jan 26 '16 at 09:15
  • 2
    Ok, thank you very much for help. I suppose that refresh and access tokens are required for more complex protocols when you don't control everything and 3d parties are involved. It's a shame there are no "simple" protocols/implementations that would satisfy the needs of many web applications, like e.g. in .NET you are forced to start an OAuth or OpenIdConnect server, otherwise you have to do it fully yourself like I do now :) – Ilya Chernomordik Jan 26 '16 at 09:19