Do OAuth2 access tokens for a mobile app have to e

问题:

The accepted answer here as to why OAuth2 access tokens expire:

• Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token. (What does this mean? I take it to mean allow transmission without TLS? Anything else?).
• Large scale deployment don't want to perform a database lookup every API call, so instead they issue self-encoded access token which can be verified by decryption. However, this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed.
• The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.

Assuming that we don't support non-encrypted transmission of the access token takes care of the first bullet point.

Assuming that we are fine with doing a database lookup against a revokable, completely random access token takes care of the second one.

For mobile apps, client authentication cannot be stronger, because "the client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret." (Google). That eliminates the third concern.

So what is the benefit of separating short-lived access tokens and long-lived refresh tokens in this scenario? Is it "okay" to just issue non-expiring access tokens and ignore the whole refresh token part?

回答1:

The difference between a refresh token and a non-expiring access token in means of security is one additional call to the authorization server.

If an attacker gains access to your non-expiring access token, he can directly call your resource server and get confidential data as response.
Now if he steals your refresh token, he first has to call the authorization server and receive an access token in response. Then he can query the resource server for confidential data.

Each time an access token is requested from your authorization server using a refresh token, the OAuth 2 specification (at least the latest draft for now) requires the server to check the client identity and if it is bound to the token, if possible.

As the normal approach with a client secret does not work to definitly identify an installed application on an open platform, the platform running the application has to provide methods to do this. Google e.g. requires Android applications to be signed by the developer. When requesting credentials for an Android application using the Google API Console, you therefore have to specify the fingerprint of the certificate you used for signing the application and only get a client ID, but no secret in response. On issuing tokens, Google can then decide if the application was authorized by the developer to request tokens in his name.

If you definitly can't verify the client identity, it is at least possible in some cases to recognize that a refresh token was stolen. The specification has an example for this:

When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.

For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.

回答2:

The biggest issue with a non-expiring access token is that there is no mechanism to replace a token that is stolen. If I get access to your non-expiring access token, then I am effectively you for that system. If the token is short-lived and expires, then there is a mechanism to replace the stolen token and a limit on the window I have to crack your token.

Let's assume it takes me 3 hours to crack a packet and get the token, but the access token is only good for two hours. Then, by the time I am unable to break into your account, the token has changed and I have to start over. If the token is non-expiring, then I have complete access to your account and you have no way to replace it short of removing the token and forcing a re-authorization.

回答3:

OAuth2 access tokens do not have to expire (or rather they do, but it can be many years hence).

An access token can be used ONCE to acquire certain resources from the resource server, in particular, it allows for the acquisition of those resources approved by the user. A refresh token on the other hand allows repeated access. Thus one cannot do away with refresh tokens without requiring user interaction between every access.

In general though, tokens can sometimes be stolen by other malicious apps on the same device, or by MITM attacks on the phone. SSL is MITM-able if the phone can be made to trust a dodgy certificate. This is sometimes required by companies to access internal networks (they require the acceptance of a self-signed certificate, which allows them to MITM all encrypted traffic occurring over the company network. Thus assuming sending the tokens encrypted means they cannot be stolen en route is dangerous.

Bearer tokens are no weaker than any other form of token per se, as proved in a bunch of papers (including one of my own, which I'll post the link to when I can dig it out.) However, bearer tokens are only appropriate in cases where the assumptions they make are valid. The assumption that the token can be kept secret is a primary assumption of bearer tokens in general. If this is not true then bearer tokens do NOT assert ANY security properties (although some do still hold). See NIST Level 3 tokens, which define what attacks bearer tokens must defeat, as specified in OAuth Bearer Tokens. In short bearer tokens are not supposed to defeat theft of the token.

Bearer tokens cannot be revoked, it is true. However given that the usual pattern of access is to use the access token immediately after acquisition, one should expire access tokens fairly quickly to prevent potential abuse, even if an abuse case cannot be thought up currently. The longer a token is around the more likely it is to be stolen. A refresh token is in fact much more dangerous to have stolen, as it provides repeat access over a longer time frame, if you cannot secure the client id. OAuth2 can provide access to resources in general, and thus for example could be used to expose APIs to a client for a time. With a refresh token significantly more damage can be done, as opposed to a single use token.

Client authentication can in fact be made more secure in a number of ways, for example, giving each client on download a different key. This prevents generalized attacks where reverse engineering a token on one device breaks the security for all instances of the client. Other potential techniques include using OAuth to verify the client with your server, which then performs a second run of the OAuth protocol with the authorization server you wish to access. This then lets you have clients that update their keys regularly, and for them all to have different keys, whilst not placing undue burden on the systems used by the Authorization server owned by Facebook or Google for example.

When using a mobile app, long-lived refresh tokens is more secure than having some sort of multi-use bearer token, even if one does not take steps to secure the client. This is because the user cannot expire the token. If the refresh token is not stolen, and the user merely wishes to revoke access then this can be done. A multi-use bearer token cannot be revoked even if the user merely wishes to revoke access. A multi-use database reference token can be revoked obviously, but this is not what the protocol is designed for and thus the security analyses that have been performed on OAuth do not say anything about the security of this hybrid system.

In conclusion I would recommend using refresh tokens and database tokens, as this is the most likely to be secure. If you can do anything to secure the client that's a bonus, but the situations this protects against are minimal. If you do want to secure the client consider soft tokens, a la google authenticator, as this is a solid implementation that has withstood analysis by some very smart people.