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?

    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>
    链接地址: http://www.djcxy.com/p/47986.html

    上一篇: oAuth2的授权码授权类型

    下一篇: 基于散列片段的安全性如何工作？