1

I am following this tutorial about OAuth2.0 https://developers.google.com/youtube/v3/guides/authentication

It looks quite clear how OAuth2.0 works. But I have a bit confusion at the access token part.

After obtaining an access token for a user, your application can use that token to submit authorized API requests on that user's behalf. The API supports two ways to specify an access token: Specify the access token as the value of the access_token query parameter:

www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN

if someone acquired this access token during the url transferring they can access this protected resource right?

How the server know if the request is coming from the client initially requested the access token?

UPDATE: after reading this post Are HTTPS headers encrypted? my confusion is cleared. I thought query string is not encrypted during transmission in the network.

Community
  • 1
  • 1
wwli
  • 2,623
  • 6
  • 30
  • 45

2 Answers2

1

Generally I think the consensus is that OAuth 2.0 is a server side technology and all access tokens and communication should be transmitted using SSL as the bearer tokens need to be kept as secure as possible.

Jammer
  • 9,969
  • 11
  • 68
  • 115
  • It seems to me in this request www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN ACCESS_TOKEN is part of url. It is not secure right? Why google passes access token like this? – wwli May 06 '13 at 21:16
0

Also, you need to know that there are 2 types of flows in OAuth 2.0
i) Implicit grant flow - This is the flow where the user logs in to the service provider and his browser gets the access token. Say you have X.com and Log in via Facebook. Once the user keys in his FB credentials, the access token is sent to his browser.

ii) Authorization Code flow - In this flow (consider the above situation again), facebook will pass an authorization code to the user's browser. If anyone, somehow, intercepts the authorization code there is nothing he can do. An authorization code can be exchanged for an access when passed with valid client credentials. So, when the user logs in, his browser gets an authorization code which is passed to your server at X.com. from there you would hit the code-token exchange endpoint provided by FB and get the access token returned to your server!

Authorization code flow adds another layer of security, where the access token is visible only to the client + server and not to the user agent. And as you figured out yourself, the token is passed via HTTPS.

divyanshm
  • 6,600
  • 7
  • 43
  • 72
  • What about the (maybe somewhat contrived) scenario where the authorisation code gets intercepted while, at the same time, the response is deliberately delayed by the malicious attacker. The attacker would then enter the intercepted URL (which has the authorization code) in his browser to get instant access to the victim's resources. Of course Mr. Evil could automate the whole process to a degree where all victims would be denied access, since the access token has already been exchanged. – simou Sep 16 '15 at 10:44