10

I am looking at implementing an authentication module using OAuth 2.0 Client and I am trying to avoid having any server state. I was going thorough a few other questions

It seems like implementing a nonce requires storing something on the server to ensure that replay attacks do not happen because the request should not occur twice.

However, this is only for authentication/authorization not for form submission data in which case implementing a nonce is easy as I would need to have server state anyway to capture the data.

So the more I look at it, it does not seem to make sense to use a nonce in this use case (except for the login, but that's the Authorization server's problem), the token (encrypted with a secret key that is on the server based on the client_secret of OAuth) I have should be fine to send (until it expires).

Is there something that I may be missing?

Community
  • 1
Archimedes Trajano
  • 334
  • 4
  • 12
  • Upvoted as this is a well structured and researched question as well as being a very interesting use case for a security primitive. – AlexH Jul 03 '14 at 15:33
  • 1
    Although i would add you may get better answers if you make your closing statement not so open ended, instead of saying "is there something im missing". – AlexH Jul 03 '14 at 16:18
  • It is pretty much going to be open ended. I would rather have some ideas to prove me wrong rather than assuming something related to security is right. Thanks though. – Archimedes Trajano Jul 03 '14 at 16:31

1 Answers1

8

From the question: "because the request should not occur twice."

No storage means no sense of history which is necessary for your requirement that something shouldn't occur twice. So the answer is no. If you want your server app to remember what happened in the past it has to be able to store that somewhere.

You could implement a nonce that was time-limited and not use-limited and that you can do without server-side storage. You just attach a timestamp to the nonce (and sign it, so the server can verify and attackers can't forge) and stop honoring it after X seconds/minutes/hours. Replay attacks would be possible but only in that time window.

Your server also needs a trusted source of time. If an attacker can make your server think it's yesterday then nonces from yesterday start working again.

u2702
  • 2,086
  • 10
  • 11
  • 1
    Interesting, I didn't think nonces can be time based (that's what I implemented in a way with OAuth2) – Archimedes Trajano Jul 08 '14 at 17:40
  • If we're talking crypto, it's probably a bad idea to re-use them. The use-case described above is more about ensuring that an action doesn't happen more than once, something like email-based password reset. – u2702 Jul 08 '14 at 18:16
  • That's true. For crypto I don't think I'd use timebased, but for authentication I think it's fine so long as it is short lived. – Archimedes Trajano Jul 08 '14 at 18:20