I'm reading the documentation about Google+ Sign In, more specifically, its server side flow. It says (https://developers.google.com/+/web/signin/redirect-uri-flow) that one-time code flow has security advantages over pure server side flow. It says:

"This one-time code flow has security advantages over both a pure server-side flow and over sending access tokens to your server."

I can see the advantages of one-time code flow vs sending access token to the server but I can't really see the advantages of one time code flow vs pure server side flow. I was wondering if somebody can point some of those out.

2 Answers 2


It seems like the only security advantage is that if using one-time code flow, browser component and server component of the client each get their own token. In pure server side flow, only server gets the token and web application flow only client gets the token. Sending token from client to server, and vice versa, exposes end user to a certain risk. Using one-time code flow there is no sending token from client <--> server and the risk of tokens being compromised is less.


"This one-time code flow has security advantages..." The statement is absolutely valid while considering one of the most dangerous attack a web application can suffer. It is the Cross Site Request Forgery (CSRF in short).

Before explaining the advantage of one-time code, let me clear the concept of CSRF. CSRF is the number 8 in OWASP list of most dangerous vulnerabilities in 2013. If a web application is vulnerable to CSRF, then it is possible to execute any script for the hacker at the user end, provided the user must be signed in. Basically what happens is the attacker will create urls or POST requests which containing malicious codes, they can be even the JS codes to grab the session cookies of the user and send to the hacker. Now these urls are send to the target user through emails and chats. The POST requests are implemented in his own site by the hacker and the link is given to the victim in the same manner. Since the user is logged in, once he click on the link the hidden scripts will be executed at the user end and he gets hacked.

The only possible prevention method against CSRF is by implementing tokens in each page. Once the user logs into his account, server assigns CSRF tokens to each pages in the web application. Now that each time any links are clicked, the CSRF token is send to the server and server gives permission only if the it accepts that token. What you have to think that a link clicked from e-mail or chat will be having a different CSRF token and hence it prevents this attack.

  • Could you please elaborate more how this relates to one-time code flow and pure server-side flow? You can use a CSRF token in both of those flows. Sep 23, 2014 at 13:18
  • Also, did you read the documentation in the links I mentioned in the question? Sep 27, 2014 at 13:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .