Should I reuse OAuth 2.0 access tokens?

Question

I am building an Authorization Server in terms of OAuth 2.0.

There is also a 3rd party web application (Client) which is using my Authorization Server. It's a regular web application, and the user may have several active sessions established with this application (for example, office and home machine, or just several web browsers on the same machine).

My Authorization Server issues an access token #1 (with or without the refresh token, that's not so important here) for Client once. When the user starts a new session with the Client, should the Authorization Server give the Client app the same access token #1 for that new session or should it issue a new #2 token?

---

My thougts:

From security point of view the new token might sound better, but then if the user wants to manage his authorizations, he will see a separate entry for each Client session, which might be messy.

For example, GitHub returns the same token for previously authorized clients, and on the "applications" page in my GitHub account I see only one entry per application, no matter how many sessions I've started, which is convenient.

However, this approach means that I have to store access tokens in Authorization or Resource server in the reversible way (plain-text or encrypted with some known key) instead of using irreversible hashing (like you usually do with passwords, storing salt and password hash from bcrypt, pbkdf2 or something similar).

Answer 1

Please be advised that I am not a security expert and this explanation is my general idea of oauth. Reason why I mentioned this in the beginning is because I see you are CREATING YOUR OWN AUTH SERVER based on oauth 2.0 protocol, which means down the road some people might be using your server for authentication, and thus I don't want you to have the wrong concept.

The session-oauth mismatch

I want to clear this first that don't mix sessions and oauth. These are two separate things usually found working together IMHO.

1. Oauth protocol simply gives the apps/users with an access token via which the app/user can query your server for data associated with the token.

2. Session on the other hand depends on the application itself. Once some app received the token, they make a session out of it. When user logs in or logs out, the session is destroyed, not the oauth.

So what is the fate of oauth token?

Well from a server standpoint, each of your token should expire after a certain time period. That is it. Server does not know anything else. It gives you the token, then expires it after 'n' seconds.

However, the app may decide that it wants to revoke the access token. Maybe their website was hacked, or maybe they are done with all api calls. Then they can send a special request to your server telling you to force-expire the token.

So what should I do about user opening multiple sessions?

ABSOLUTELY NOTHING. As an oauth service provider, you are not concerned with sessions at all. All you know is that if the app asks you for a token, you give them one.

However, I will answer you question about sessions as well. Should you spawn different sessions for the same user? I would say yes. If you have same session, then if you log out from one machine, and refresh the page in second machine, since the session has expired, your other browser/machines will also log out naturally.

So how does github manages to not show extra entries?

Well I do not work for them so I don't know. But I guess that they will check each session, and if two or more sessions are associate with the same user, they know the user must be using many devices. Then when one of your devices sends some request to github, they can guess from the IP address your location, and if many of your machines are making requests from same place, you got to be using multiple machines. If not, then maybe some attacker is using your account as well.

This is how AFAIK banks predict malicious users - well not the only way, they sometimes also predict the pattern you are using to access bank records, and if that pattern is different, there are good chances that your account was compromised.

So now you may ask me, are you really sure that I should create as many tokens as the app demands me?

This is the part where I am not so sure. From what I have seen, oauth has two things. Google these two terms for more info:

1. Refresh Token: This token is not your access token. This token never expires, and once your access token is expired, you can use this token to get a new access token. This token is also to be kept secret.
2. Offline access type: Many oauth providers such as google and facebook also support this mode. This mode basically allows you to extend the expiry time of your access token. E.g. instead of normal expiry time of access token (e.g. 1 hour), for offline tokens you might have the expiry time of 1 year or so.

Answer to the question "Should I reuse OAuth 2.0 access tokens?"

Yes, the token is supposed to be used as many times as you need within the given expiry time (google sets it to 1 hour). After it has expired, use the refresh token to get another access token and use it as many times as you need. Keep repeating the process.

If your users won't be online for you to start the oauth process, and you don't have the refresh token, then the app needs to have "offline" tokens.

Should I store my auth tokens?

You can if your app demands it, but it is nowhere recommended because of the potential to be leaked. Tokens are supposed to extract data within the given time limit and reissue the token when needed again. However, you surely can store them if you want.

"Offline" tokens, on the other hand, are expected to be stored. You can encrypt them if you like, but if the scopes are not too broad, I wouldn't bother at all.