With reference to the omniauth-google-oauth2 gem which describes what it calls "One-time Code Flow (Hybrid Authentication)" as such:

This hybrid authentication flow has significant functional and security advantages over a pure server-side or pure client-side flow.

The readme then goes on to describe the mechanics of the flow itself, and finishes with:

This flow is immune to replay attacks, and conveys no useful information to a man in the middle.

I haven't been able to find any explanation on the web about why this is so, or how it is superior to purely server-side OAuth 2.0 authentication. Most material seems to talk only about the mechanics of various OAuth strategies.

More specifically, what I don't understand is this: if it's the same information flowing between either client/server/auth provider or just server/auth provider, then isn't either strategy just as susceptible to attacks?

up vote 3 down vote accepted

So as you have described, a "Hybrid Authentication" is a middle solution between pure server-side and pure client-side authentication. That means that all the tasks that are involved to get an authentication complete will need both the server and the client.

This is how a server-side authentication occurs:

  • you click signin button
  • you get the consent dialogue asking for your permission
  • you have to specify a (redirect URI)
  • you get 2 things:

    1- get redirected to the redirect URI

    2- get a code appended to the redirect URI (User ID Token)

  • you exchange the (User ID Token <-> Access Token, Refresh Token) from the google authorization server #NOT SECURE

This is how a one-time code flow occurs:

  • you click Sign In button (a state variable gets created in the background)
  • you get the consent dialogue asking for your permission
  • you have to specify a (redirect URI)
  • you get 2 things:

    1- get redirected to the redirect URI (#State Variable gets redirected back with you)

    2- get a code appended to the redirect URI (User ID Token)

  • you exchange that code with your server #VERY SECURE (You hand in the code + state variable, and the server compares that state variable with the one that it has already) #NO CSRF

  • server exchanges the (User ID Token <-> Access Token, Refresh Token) from the google authorization server

So this exchange here is immune to both replay attacks and doesn't provide a MITM with any useful information, because even if the attacker intercepted any packets, he will still have to get that state variable and process the appended code through the server. In contrary to the pure server-side implementation where all the attacker has to do is to send the code to google in exchange with the access token and the refresh token.

Here is also a picture to put things into perspective, hope that the difference is more clear now.

One-Time Code Flow Representation

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.