16

I'm learning OAuth 2.0 and couldn't get the way of securing access token in implicit grant flow. There are some theses in specification and some upvoted SO answers looking contradicting to each other. Could somebody clear it up? Quotes from SO answers and specification that are confusing me:

  1. (From spec) Redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent.
  2. (From spec) Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. Access token credentials MUST only be transmitted using TLS.
  3. (From accepted and upvoted SO answer) In the implicit flow the access token is passed as a hash fragment, only the browsers are aware of hash fragment. Browsers will pass the hash fragment directly to the destination webpage/the redirect URI which is the client's webpage (hash fragment are not part of the HTTP request) so you have to read the hash fragment using Javascript. Hash fragment cannot be intercepted by intermediary servers/routers (this is important).

My question:

P1 says that token delivered to client via Redirection URI and P2 says delivery channel MUST be TLS-ed. But P3 says that hash fragment not sending to the network. How access token reaches client if it is not sending because it's hash fragment? Anyway, it has to be sended by network isn't it? Or sending token with redirection URI makes some magic without network deals?

The only probable explanation - under the hood browser sends only non-hash part of url by network and after loading new page, just inserts hash fragment and make it available to JS. If I'm right I still can't understand why don't we simply send token with reliable, secured HTTPS channel as response parameter?

Community
  • 1
  • 1

1 Answers1

13

The OAuth Provider sends the Access Token back to the OAuth Consumer with a HTTP Response redirect:

HTTP/1.1 302 Found
Location: https://consumer.org/redirect_uri#access_token=1111-2222-3333-4444

Note how the access token is sent through the network, as part of the HTTP response from the OAuth Provider, which ALSO should be on HTTPS in addition to the consumer.

Your browser will then perform a new HTTP GET request to the consumer endpoint:

GET /redirect_uri HTTP/1.1
Host: consumer.org

Note how the access token is NOT sent to the consumer through the network. The server at consumer.org will not receive the token in this HTTP request. Instead the web page returned from https://consumer.org/redirect_uri will contain javascript that is able to and will read the access token from the url fragment.

Consequently, you need to trust the javascript code that you receive from consumer.org (by using HTTPS) because if an attacker can inject code, it can also indirectly obtain the access token (and send it anywhere).

Example of HTTP response from the consumer:

200 OK
Content-Type: text/html

<html><head><script> 
    alert(window.location.hash) 
</script>
</head><body></body></html>
Maria Ines Parnisari
  • 16,584
  • 9
  • 85
  • 130
Andreas Åkre Solberg
  • 1,705
  • 12
  • 11
  • about malware JS code and HTTPS - yes, probably HTTPS setup on client solves bad JS problem but doesn't hash-fragment magic invented for non-HTTPS clients? If hash-fragment can't fully defend from attacks like bad JS isn't it better to simply use HTTPS on client and send token as request parameter? –  Sep 12 '14 at 03:30
  • 2
    No, implicit grant flow is not for non-https clients, it is for clients that does not have a backend. There is no flow where token is sent as request parameter. In contrast to implicit grant flow, the authorization code flow, provides the `code` as a query string parameter to the client backend. The client backend then exchange the code with a token (authenticated request with client credentials) – Andreas Åkre Solberg Sep 12 '14 at 09:08
  • 1
    The original redirection response which had the token after the # is gone because after receiving 302, the browser is making a new GET request right? 1. In the GET request to the consumer.org/redirec_uri if the part after the hash that is token is not sent then when the JS will be returned by the consumer.org where will the JS find this "token" because the URL used to retrieve this JS doesn't have a token now? 2. If the IDP(OAuth) provider returned the token in the redirect URL then isn't that exposed to the internet? or the response headers are not exposed to the Internet? – Akshay Hiremath May 18 '21 at 03:44