3

I implemented my own Json Web Tokens authentication and authorization scheme, which is based on three tokens - access token, reference token and refresh token. They are generated by backend or application code and all authorization logic is implemented in middleware (in Lua code embedded in nginx).

These are some questions that are bothering me:

  1. Should I sign my reference token with RSA before I pass it to the client?
  2. Should I sign my refresh token with RSA? Obviously, like reference token, it does not store any critical information and therefore I'm not sure of that.
  3. Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just like in case of hashed passwords stored in database.
  4. What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some arbitrary header like X-Reference-Token?
  5. In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a standard convention) or is it ok to use just the same X-Reference-Token: ...
  6. Is it secure (I guess, not) to pass refresh token to the client. And if not, how do they store it? Reference token is stored in client side cookies and passed with each request from client to the server, access token is never passed to the client and is stored in server side cache and where should I store my refresh token?
  7. Is it secure to use raw reference token value as a key, by which I get access token from server side cache? Let's say, my reference token is just some GUID, is it secure enough to use this very GUID as a key by which my access token is stored? Or is it more secure to get this key from GUID by some transformations?
  • 2
    This has waaaay too many questions. This needs to be broken down into multiple smaller questions. – Steve Aug 21 '17 at 15:16
  • @Steve. I have already broken down it into seven questions and I'm not sure, if I should make separate big questions like - "What is a standard way to name HTTP header for reference tokens?" – Jacobian Aug 21 '17 at 19:04
0
+100

There are a lot of unknowns here but here is my shot at answering based on general security best practices.

  1. Should I sign my reference token with RSA before I pass it to the client?

Signatures can be used for authenticity, integrity, and non-repudiation. In this case, integrity is the only one which seems to make sense. If this is required, you should definitely sign the token. It is required, if the token is self-describing, i.e. contains data which may be manipulated by the client (like a JWT). I wrote blog post on integrity. RSA may not be required. A simple HMAC may be enough for you. Your use case really determines if you need asymmetric crypto here.

  1. Should I sign my refresh token with RSA? Obviously, like reference token, it does not store any critical information and therefore I'm not sure of that.

See 1. Since you do not pass it to the client and it seems to be an opaque token. You can get away with not signing this.

  1. Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just like in case of hashed passwords stored in database.

See 1. Not passing it to the client, make it impossible to be modified by the client. Integrity may still be required, it depends on your use case.

  1. What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some arbitrary header like X-Reference-Token?

Yes, it is fine. Since the scheme is custom, I do not think there is harm in using a custom header for a custom piece of token.

  1. In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a standard convention) or is it ok to use just the same X-Reference-Token: ...

Authorization: Bearer is probably better here. However it seems in 6. that your are using cookies for the reference token, in which case there is no need for an extra header to send it.

  1. Is it secure (I guess, not) to pass refresh token to the client. And if not, how do they store it? Reference token is stored in client side cookies and passed with each request from client to the server, access token is never passed to the client and is stored in server side cache and where should I store my refresh token?

Your scheme is a black-box to me, but it seems like the access token never hits the client, therefore the refresh token should not either. In a regular auth mechanism like OAuth these two tokens require the same amount of security. Not counting the fact that refresh tokens live longer.

  1. Is it secure to use raw reference token value as a key, by which I get access token from server side cache? Let's say, my reference token is just some GUID, is it secure enough to use this very GUID as a key by which my access token is stored? Or is it more secure to get this key from GUID by some transformations?

Again your scheme is a black-box. It seems to me that your reference token is actually a session ID. In which case it should not be a GUID, but a random opaque token, as described here. It is fine to store the session ID as the key to get the access token from your cache.

Anything I described above is based on my very limited understanding of your scheme. Generally, you should not run your own authentication/authorization scheme. It seems to me you have a web application with session management using cookies and an OAuth to access some resources on the backend.

Take a look at OAuth, it may well simplify your life quite a bit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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