Purpose of nonce validation in OpenID Connect implicit flow

  • The OpenID Connect specification requires implicit flow clients to generate and validate a nonce:

    String value used to associate a Client session with an ID Token, and to mitigate replay attacks.

    What replay attacks are those?

    Put differently, what is the security impact of not validating the nonce when using the implicit flow?

    See my response here: https://security.stackexchange.com/questions/147529/openid-connect-nonce-replay-attack/214586#214586 It presents a few example attack vectors, and how the nonce mitigates them.

  • My current understanding is as follows:

    The client (a web application running in the user's browser) generates a nonce, puts it into the browser's session storage, and redirects to the authentication server, passing the nonce as parameter. After authentication, the authentication server redirects back to the client, passing a signed id token containing the nonce, which the client must validate against the nonce from the session storage.

    If the nonce is not validated, an attacker could substitute another id token, by tricking the user into visiting his site, and sending a redirect with a valid id token obtained from a different request.

    In addition to the id token, the authentication server also replies with an access token. If the nonce is not validated, an attacker could substitute a different access token, by tricking the user onto his site, and redirecting with that token. This might be used for a client side denial of service attack (in particular if browser tabs share the token storage, i.e. use local rather than session storage).

    In summary, nonce validation is necessary to trust the id token. If the id token need not be trusted, nonce validation may be skipped.

    In authorization endpoint the `state` is meant for protecting against CSRF, XSRF on the client side redirect URI. `nonce` is meant to protect the server side replay attacks and must have implementation on the server.

    @Cicantic: I don't get what CSRF has to do with this? Care to explain? (Did you mean to write an answer rather than comment on mine?)

    `an attacker could substitute another id token` and then what?

    The nonce effectively acts as a password for the client application. See my response to a similar question which provides some replay attack examples and describes how the nonce helps to prevent those: https://security.stackexchange.com/questions/147529/openid-connect-nonce-replay-attack/214586#214586 Also, what @Ciantic says is not entirely accurate. The nonce is required in the implicit flow, and in that flow there generally is no server (if your application has a back-end server then you should be using the code flow).

  • Giving a wild idea of replay packets and Use of nonces. This Dosen't deal with OpenId its my general idea.

    Suppose in the communication of two parties A and B; A is sharing his key to B to prove his identity but in the meanwhile Attacker C eavesdrop the conversation between them and keeps the information which are needed to prove his identity to B.

    Later C contacts to B and prove its authenticity.

    Example :if A has a nonce cache which stores a pseudo random nonce number.B uses this directly to make the reply packet. A than it clears the cache when it gets the first reply packet from B.

    For next transmission again a fresh random nonce is saved in nonce cache of A. And used to transmit packet to B.

    If C after some times try to replay a packet to A. A will discard due to wrong nonce.

    Note:Nonces can encrypted and send . There can be multiple ways to use nonces according to the protocol.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM