How does Oauth 2 prevent replay attacks in mobile applications?

Question

This question has come up a lot but I haven't discovered the answer. I've read the OAUTH 2 spec and the separate security "considerations" document but I'm still fuzzy on something.

The circumstance is: RESTful based web services being accessed by mobile applications. I am both the server resource (creator and host of the RESTful services) and the authorization authority (I store the user's IDs and passwords and validate identity). Third party companies create the mobile applications that consume my services. I am using OAuth 2.0 to validate the user's UserID and Password and issue a token. TLS via https is used.

A nonce with a singed message is commonly used to prevent against replay attacks but as I understand it, that won't work in a mobile application because in order to sign a message, you need a shared secret. Any secret stored on a mobile app (that would allow you to sign messages) is no longer a secret. So a nonce can't be used.

So we have session tokens, which expire after some configurable period of time, and can be refreshed with a "refresh token".

My question is: If TLS is defeated (example: user is dumb enough to connect their mobile phone to a proxy server and install a certificate of the proxy, which then allows the proxy-server owner to read the unencrypted traffic), what prevents a hacker from replaying a request with a valid session token (while it's still alive), or worse, persisting the session for hours at a time using the refresh token to continuously obtain new session tokens?

Answer 1

The situation you suggest is one where the security is defeated and there is no security. The proxy can do things like steal the user's password during authentication or divert the access token to another application (either local or remote). You must just accept this scenario as a loss.

Also, it is typical for mobile apps to have a shared secret. As you point out, the secret loses some security being on the client, but it is still better than nothing. The secret is typically encrypted while at rest to prevent it from easily being stolen. Of course, the decryption key can be stolen from the app even when obfuscation techniques are applied to it but it provides some security.

Be sure to restrict the access rights of the secret on the client. Make sure that it is not configured for 2-legged auth. That should be saved for servers and only when needed.