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: <ol> <li>(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.</li> <li>(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.</li> <li>(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). </li> </ol> 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?

The OAuth Provider sends the Access Token back to the OAuth Consumer with a HTTP Response redirect: <pre class="prettyprint"><code>HTTP/1.1 302 Found Location: https://consumer.org/redirect_uri#access_token=1111-2222-3333-4444 </code></pre> 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: <pre class="prettyprint"><code>GET /redirect_uri HTTP/1.1 Host: consumer.org </code></pre> Note how the access token is NOT sent to the consumer through the network. The server at <code>consumer.org</code> will not receive the token in this HTTP request. Instead the web page returned from <code>https://consumer.org/redirect_uri</code> 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: <pre class="prettyprint"><code>200 OK Content-Type: text/html <html><head><script> alert(window.location.hash) </script> </head><body></body></html> </code></pre>

How exactly hash fragment based security works?

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:

(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.
(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.
(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?

What are hash fragments?

A hash sign (#) in a URL is referred to as a fragment. Historically, URL fragments have been used to automatically set the browser's scroll position to a predefined location in the web page. In that sense, if a URL refers to a document, then the fragment refers to a specific subsection of that document.

Is URI fragment sent to server?

Fragment identifiers are not sent to the server. The hash fragment is used by the browser to link to elements within the same page.

Can a URL have more than one fragment?

A URL cannot have more than one fragment. URL parameters are passed in key-value pairs. URL fragments comprise just a string of text after the hash (#).

Which part of the URL is called the fragment or hash?

The fragment identifier introduced by a hash mark # is the optional last part of a URL for a document. It is typically used to identify a portion of that document.

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>

How exactly hash fragment based security works?

Tags:

java

oauth

user-agent

oauth-2.0

Baurzhan

People also ask

1 Answers

Andreas Åkre Solberg

Recent Activity

Donate For Us

How exactly hash fragment based security works?

Tags:

java

oauth

user-agent

oauth-2.0

Baurzhan

People also ask

1 Answers

Andreas Åkre Solberg

Related questions

Recent Activity

Donate For Us