0

I'm very confused as to how the nonce parameter is actually used for OpenID Connect. I am trying to authenticate users via Microsoft Azure and Google, sign in with Azure and Google respectively.

Here is my current (implicit) flow.

  1. When the user loads our sign in page in the browser, the two client libraries, google and azure msal are initialized with our client IDs.
  2. There are two buttons on the sign in page each one opens a popup from the respective providers that redirect to the Google/Microsoft sign in pages.
  3. The user enters their Google/Microsoft username and password and signs in. The popup window closes upon successful authentication and an ID token is returned to the browser JavaScript.
  4. The browser JavaScript takes the ID token and sends it to our back-end and we validate the JWT in our back-end.
  5. Upon successful validation we create a session for the user and we redirect the browser to the dashboard.

I'm confused as to where the nonce fits in with all of this, is not needed since I am using a JavaScript based flow instead of HTTP? Is it being handled implicitly by the browser client libraries?

How can I ensure that an attacker can't sniff the ID token between the Google/Microsoft server and browser AND browser and back-end and just re-send that ID token to authenticate as the user?

identigral
  • 3,920
  • 16
  • 31
skyguy126
  • 457
  • 1
  • 5
  • 17

1 Answers1

2

The nonce is quite similar to state and also serves to counter replay attack. The main difference is nonce is returned back in the id_token whereas state is returned back in the redirect URI. Usually the library should generate it for you and verify in the id_token.

Btw if you have access to the back-end, I would recommend using code flow instead (or at least the new PKCE flow) as the implicit flow would be deprecated soon.

Son
  • 1,835
  • 2
  • 18
  • 28
  • I don't see or configure either the nonce or state parameters with regards to either provider. Are they just happening implicitly in the front-end libraries? I am also using implicit flow because the app is a single page app and all actions are basically REST API calls. Essentially I am exchanging the google/microsoft ID token for a token generated by the backend. Then we used this new token for all REST calls. – skyguy126 Aug 20 '19 at 21:48
  • 1
    Usually libraries take care of generating the nonce but some might not ... Have you tried using the the code flow but sends the code to your backend via a REST call, then your back-end can exchange for an access token and then user info via a server-to-server call? The `id_token` is **not** encrypted so if someone can get hold of it, they can see the user information inside. – Son Aug 20 '19 at 21:58
  • What exactly is the purpose of the implicit flow if not for backend authentication - Google has documentation on backend authentication using the implicit flow which is why I was wondering. I do have certain reasons for using the implicit flow, one to avoid redirects. https://developers.google.com/identity/sign-in/web/backend-auth – skyguy126 Aug 20 '19 at 22:09
  • The redirect can be avoided if the authorization page is opened as a popup, please have a look at https://docs.simplelogin.io/docs/frontend-js/ (disclaimer: I'm SimpleLogin founder). I just look at the google link you sent, it's very surprising that Google recommends this "anti-pattern"! `Id_token`, contrary to its name, it's not a "secret" , it's simplify a **encoded** json. – Son Aug 20 '19 at 22:18
  • Yes I see your simple login library, my code right now does the same thing, it fetches the userinfo JWT directly in the front end itself - no connection to the backend. Then we pass the JWT into the backend to exchange it for an API key given the user's email is present in our DB. I thought you said this was poor strategy? – skyguy126 Aug 20 '19 at 23:21
  • I think unless the back-end cannot make calls to outside, the "code" flow is better in terms of security. The flow Google recommends would also work, it just seems a bit redundant to me as both the front-end and back-end need to make a call against Google Auth Server to verify the id_token. And soon that the implicit flow is obsolete (https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead), I wonder what they would recommend ... – Son Aug 21 '19 at 08:29