title: How does Oauth 2 prevent replay attacks in mobile applications?
body: <p>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.</p>
  
  <p>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. </p>
  
  <p>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. </p>
  
  <p>So we have session tokens, which expire after some configurable period of time, and can be refreshed with a "refresh token". </p>
  
  <p>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?</p>