Subject: [OAUTH-WG] Confusion on Implicit Grant flow

From: Adam Lewis <[email-masked]>
Date: Fri, 6 Feb 2015 21:27:35 +0000

Hi,

Having spent most of my time with native apps and web apps, I now am looking at use cases where I need to implement a user-agent-based app.  The Implicit flow seems to be optimized for this.

To test my understanding, this flow is for a JavaScript client (or similar) executing within a web browser.

At step (a) the client directs the UA to the authorization server, but the authorization server redirects the UA to a web-hosted client resource.  Why?  It says so that the web-hosted client resources can push javascript (or other) back into the UA so it can extract the access token in the fragment; but some sort of javascript is already running in the browser, since it initiated the authorization request in the first place.  So why this extra step?  Why not treat the javascript client running in the UA like a native app and handle the redirect uri?

I know this was well thought out when the spec was written, so trying to figure out what I'm missing?

Tx!
adam

---

From: John Bradley <[email-masked]>
Date: Fri, 6 Feb 2015 18:37:39 -0300

It isn’t an extra step,  the call back via 302 has to be to a URI in the location header.  The JS loaded by that URI may already be cached in the browser as part of the APP.

The cached JS typically extracts the token and uses it.  The token is never passed to the server where the JS is loaded from. (yes it could be, but if your are doing that then use code or hybrid code+token)

Ther are other ways that could be done using pure Java Script cross origin messaging eg post-message.   However though some people (Google and others) do use that in there custom integrations, a standard for that has not been established.
(there are some real security issues around post message that need to be considered first)

John B.

> On Feb 6, 2015, at 6:27 PM, Adam Lewis <[email-masked]> wrote:
> 
> Hi,
>  
> I know this was well thought out when the spec was written, so trying to figure out what I’m missing?
>  
>  
>  
> Tx!
> adam
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Josh Mandel <[email-masked]>
Date: Fri, 6 Feb 2015 13:40:45 -0800

Hi Adam,

I'm not 100% sure what you're envisioning as an alternative to the implicit
flow, but if I'm reading between the lines of your question correctly,
there are two key parts to the answer, because the implicit flow is
designed to accomplish two key goals (vs. the authorization code grant):

1. Shave off one round-trip HTTP request (the step of exchanging a code for
a token)
2. Avoid unnecessarily leading the token to the client's back-end web server

Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server with
an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon S3
without having access tokens leak to Amazon. (Of course, if your threat
model includes a compromised server, then bets are off on this point.)

Hope this helps,

  -Josh

On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis <[email-masked]
> wrote:

>  Hi,
>
>
>
> Having spent most of my time with native apps and web apps, I now am
> looking at use cases where I need to implement a user-agent-based app.  The
> Implicit flow seems to be optimized for this.
>
>
>
> At step (a) the client directs the UA to the authorization server, but the
> authorization server redirects the UA to a web-hosted client resource.
> Why?  It says so that the web-hosted client resources can push javascript
> (or other) back into the UA so it can extract the access token in the
> fragment; but some sort of javascript is already running in the browser,
> since it initiated the authorization request in the first place.  So why
> this extra step?  Why not treat the javascript client running in the UA
> like a native app and handle the redirect uri?
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Bill Burke <[email-masked]>
Date: Mon, 09 Feb 2015 15:05:43 -0500

Due to the security risks of implicit Grant flow, our Javascript adapter 
only supports  Auth Code Grant flow.  Our IDP has an extra step of 
allowing you to specify a valid CORS origin for an application.  Anybody 
see any problems with this kind of approach?  Implicit Grant Flow just 
seemed really risky to even support as a protocol.

On 2/6/2015 4:40 PM, Josh Mandel wrote:
> Hi Adam,
>
> I'm not 100% sure what you're envisioning as an alternative to the
> implicit flow, but if I'm reading between the lines of your question
> correctly, there are two key parts to the answer, because the implicit
> flow is designed to accomplish two key goals (vs. the authorization code
> grant):
>
> 1. Shave off one round-trip HTTP request (the step of exchanging a code
> for a token)
> advantage of the fact that a URL's "#hash" is not sent to the server
> with an HTTP request. By embedding the token in a "#hash", it won't
> flow, I can (for example) statically host a browser-based app at Amazon
> S3 without having access tokens leak to Amazon. (Of course, if your
> threat model includes a compromised server, then bets are off on this
> point.)
>
> Hope this helps,
>
>    -Josh
>
>
>
> <mailto:[email-masked]>> wrote:
>
>     Hi,____
>
>     __ __
>
>     looking at use cases where I need to implement a user-agent-based
>     app.  The Implicit flow seems to be optimized for this.____
>
>     __ __
>
>     To test my understanding, this flow is for a JavaScript client (or
>     similar) executing within a web browser.____
>
>     __ __
>
>     At step (a) the client directs the UA to the authorization server,
>     but the authorization server redirects the UA to a web-hosted client
>     resource.  Why?  It says so that the web-hosted client resources can
>     push javascript (or other) back into the UA so it can extract the
>     access token in the fragment; but some sort of javascript is already
>     running in the browser, since it initiated the authorization request
>     in the first place.  So why this extra step?  Why not treat the
>     javascript client running in the UA like a native app and handle the
>     redirect uri?____
>
>     __ __
>
>     I know this was well thought out when the spec was written, so
>     trying to figure out what I’m missing?____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     Tx!
>     adam____
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Feb 2015 17:16:04 -0300

If you don't have a client secret, or are storing the the client secret in the Javascrypt, then you are probably more at risk using code than implicit.

Implicit is risky because running a OAuth client in the browser is risky.  Using code in that case makes it no better, and arguably worse.

Perhaps I don't understand the environment.

John B.

> On Feb 9, 2015, at 5:05 PM, Bill Burke <[email-masked]> wrote:
> 
> Due to the security risks of implicit Grant flow, our Javascript adapter only supports  Auth Code Grant flow.  Our IDP has an extra step of allowing you to specify a valid CORS origin for an application.  Anybody see any problems with this kind of approach?  Implicit Grant Flow just seemed really risky to even support as a protocol.
> 
>

---

From: Bill Burke <[email-masked]>
Date: Mon, 09 Feb 2015 15:50:15 -0500

If you don't have a client secret, why is Javascript-based auth code 
grant flow more risky?  We also require SSL and valid redirect URI 
patterns to be registered for the application.  The code can only ever 
be sent to specific URLs and can only be used once.  CORS origin 
validation is also an extra step we do to ensure a rogue javascript app 
isn't making any code-to-token requests.

I'm just trying to figure out if we missed anything...

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Feb 2015 18:02:52 -0300

You are passing code in a query parameter, and without a secret that is more likely to be leaked than sending token in the fragment directly from the authorization endpoint to the browser JS in a fragment.

You have several extra round trips for no security benefit.   In your case the code in the query parameter goes from the browser to the redirect endpoint then must be sent back to the browser, and then to the token endpoint.

So yes using code for that is less secure.

Both rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS.

John B.
> On Feb 9, 2015, at 5:50 PM, Bill Burke <[email-masked]> wrote:
> 
> If you don't have a client secret, why is Javascript-based auth code grant flow more risky?  We also require SSL and valid redirect URI patterns to be registered for the application.  The code can only ever be sent to specific URLs and can only be used once.  CORS origin validation is also an extra step we do to ensure a rogue javascript app isn't making any code-to-token requests.
>

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 09 Feb 2015 13:21:15 -0800

The implicit flow depends upon a subtle and little known aspect of 
browser behavior - that the URI fragment component isn't propagated 
across redirects.

I havent checked this recently - but I am aware that several folks have 
found that some browser versions dont comply with this requirement.
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2

The additional round-trip issue is also unclear. The implicit flow 
requires an additional redirect (round-trip) to retrieve JS which 
retrieves the access token from the fragment URI.

How is that different from a HTTPs callback to exchange the access code 
for the access token?

- prateek

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Feb 2015 18:31:17 -0300

Typically the implicit callback JS is part of the application that is already loaded and cached in the browser.

The implicit flow doesn’t depend on on the fragment not being re-appended to the resource location URI in the 302.  It would admittedly be more secure if that didn’t happen.  
Re-appending the fragment is the correct browser behaviour according to the W3C.

I still think you are farther ahead with that than leaking the code in the referrer.

Implicit if done correctly has the token in one leg.  code on the other hand has the code in 4 legs and the token in one.

It is having the JS make the exchange of code for the AT without a secret that is the problem in my opinion.

If the client is a server that is doing the code -> token exchange then the answer is different, but the question was for a JS only client.

John B.

> On Feb 9, 2015, at 6:21 PM, Prateek Mishra <[email-masked]> wrote:
> 
> The implicit flow depends upon a subtle and little known aspect of browser behavior - that the URI fragment component isn't propagated across redirects. 
> 
> I havent checked this recently - but I am aware that several folks have found that some browser versions dont comply with this requirement.
> http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2 <http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2>
> 
> The additional round-trip issue is also unclear. The implicit flow requires an additional redirect (round-trip) to retrieve JS which retrieves the access token from the fragment URI. 
> 
> How is that different from a HTTPs callback to exchange the access code for the access token?
> 
> - prateek
> 
>>> On Feb 9, 2015, at 5:50 PM, Bill Burke <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>>>> On Feb 9, 2015, at 5:05 PM, Bill Burke <[email-masked]> <mailto:[email-masked]> wrote:
>>>>> 
>>>>>> On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
>>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>    Hi,____
>>>>>> 
>>>>>>    __ __
>>>>>> 
>>>>>>    [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>>>> 
>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>> 
>>

---

From: Bill Burke <[email-masked]>
Date: Mon, 09 Feb 2015 16:44:28 -0500

For implicit flow, wouldn't the token be available in the browser 
history and could also possibly be bookmarked by accident or on purpose? 
  If a code is bookmarked, so what?  It is only valid for a tiny window 
(milliseconds).

Please tell me how a code is more likely to be leaked without a client 
secret when it can only be sent via SSL to a validated URL.

On 2/9/2015 4:02 PM, John Bradley wrote:
>>>>> <[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Feb 2015 19:03:49 -0300

OK, I don't know if the WG has discussed the issue of fragments in browser history.  

So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?

One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs. 

On the wire with a registered https redirect implicit has less hops to protect, but you are correct that in the browser there might be threats that could extract the AT from the fragment if it is logged in the browser.

The real answer will eventually be using token binding to lock AT to browser instances.   

John B.
> On Feb 9, 2015, at 6:44 PM, Bill Burke <[email-masked]> wrote:
> 
> For implicit flow, wouldn't the token be available in the browser history and could also possibly be bookmarked by accident or on purpose?  If a code is bookmarked, so what?  It is only valid for a tiny window (milliseconds).
> 
> Please tell me how a code is more likely to be leaked without a client secret when it can only be sent via SSL to a validated URL.
> 
>

---

From: Bill Burke <[email-masked]>
Date: Mon, 09 Feb 2015 17:32:24 -0500

> So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?

Yes, bookmarking tokens is a little scary, IMO, as we've already run 
into users bookmarking URLs with codes in them.

Also, wasn't there additional security vulnerabilities surrounding 
implicit flow?  Maybe these were just the product of incorrect 
implementations, I don't remember, it was a while ago.

> One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs.

It looks like OIDC added a "response_mode" parameter where you can 
specify "query" or "fragment".  Thanks for pointing this out!

Thanks for all the help.

---

From: "Reddick, Anwar" <[email-masked]>
Date: Mon, 9 Feb 2015 22:42:08 +0000

Hi Bill,

I'm not sure if I have permission to post to the OAuth list. Anyway, if your page that does the OAuth processing includes third party scripts, then those scripts will probably have access to the code, client secret, and access token. I believe this concern is addressed in the security section of RFC 6749.

E. Anwar Reddick
Research Scientist
Georgia Tech Research Institute

----- Reply message -----
From: "Bill Burke" <[email-masked]>
To: "John Bradley" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [OAUTH-WG] Confusion on Implicit Grant flow
Date: Mon, Feb 9, 2015 5:33 PM

Thanks for all the help.

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Feb 2015 19:59:04 -0300

The security problem was people only doing host name matching on redirect_uri and attackers finding redirectors to use.   That impacted all public clients not just implicit.  
Implicit took most of the heat because that was what Facebook was using, and they had the largest issue.

Connect has a response_mode that allows the response to be form encoded rather than fragment.  
I read RFC 5849 as only allowing code to be query encoded.   The response_mode was intended for the new response types we defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

The spec for response mode is here http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.

John B.
> On Feb 9, 2015, at 7:32 PM, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> Yes, bookmarking tokens is a little scary, IMO, as we've already run into users bookmarking URLs with codes in them.
> 
> Also, wasn't there additional security vulnerabilities surrounding implicit flow?  Maybe these were just the product of incorrect implementations, I don't remember, it was a while ago.
> 
> It looks like OIDC added a "response_mode" parameter where you can specify "query" or "fragment".  Thanks for pointing this out!
> 
> 
> Thanks for all the help.
> 
> 
> -- 
> Bill Burke

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 10 Feb 2015 10:16:30 +0000

Hi John
> We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.
What is your opinion on providing a feature 'symmetric' to the one where 
a signed and/or encrypted code request is passed to AS ? The feature 
would return a signed and/or encrypted code in the redirect URI as usual.

I'm not sure it would help the implicit clients though...Unless the 
encryption key can be derived from a combination of the client_id and 
some extra piece of information encoded in the JS script but also known 
to AS (via the registration, etc)

Thanks, Sergey

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Feb 2015 05:06:39 -0700

On Mon, Feb 9, 2015 at 3:59 PM, John Bradley <[email-masked]> wrote:

> I read RFC 5849 as only allowing code to be query encoded.   The
> response_mode was intended for the new response types we defined in
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>

Actually response_mode is defined in that spec itself in section 2.1
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes>.

>
> The spec for response mode is here
> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>

And that spec is actually to define a new response mode, form_post, which
encodes authorization response parameters as HTML form values that are
auto-submitted (via javascript) by the user agent and transmitted via HTTP
POST to the Client’s redirect URI.

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Feb 2015 10:15:08 -0300

The issue is maintaining key material in the browser.

Web Crypto will help with that , but is not deployed widely in browsers at the moment.

Thinking about it a bit someone could make a more secure flow for JS clients using code and some Connect extensions now.

If I were concerned about logging the AT, then I would have the JS make a CORS call to the authorization endpoint with:
response_type=code+id_token              [http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html]
code_challenge=(challenge value)        [ https://tools.ietf.org/html/draft-ietf-oauth-spop-02]
code_challenge_method=S256

The response is fragment encoded,  and the id_token contains a detached sig of code for the JS to verify along with the client as the "aud" signed with RSA key of the AS as the default.
The JS would be the callback URI and extract the code and id_tokens

The JS then makes a CORS call to the token_endpoint sending
code_verifier=(verifier value)

Code could be logged but wouldn't be usable without knowing the code_verifier.
This effectively turns the JS into a semi confidential client.    

We have been looking at PKCE/SPOP for native apps, but nothing would stop it from working with JS clients.

In Connect the JS client crates a nonce value and sends that with the request.  That value comes back in the signed_id token allowing the JS to know that the code and id_token are in reply to it's request and not replayed from another session.

I think using token binding to associate the JS clients TLS key to the AT so that it cannot be replayed from a different browser is the best option over the longer term.
That provides the best protection from plugins and scripts extracting the AT from the running JS.

John B.

> On Feb 10, 2015, at 7:16 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi John
> What is your opinion on providing a feature 'symmetric' to the one where a signed and/or encrypted code request is passed to AS ? The feature would return a signed and/or encrypted code in the redirect URI as usual.
> 
> I'm not sure it would help the implicit clients though...Unless the encryption key can be derived from a combination of the client_id and some extra piece of information encoded in the JS script but also known to AS (via the registration, etc)
> 
> Thanks, Sergey
> 
> 
> 
> 
>> John B.

---

From: Bill Burke <[email-masked]>
Date: Tue, 10 Feb 2015 08:35:07 -0500

On 2/10/2015 7:06 AM, Brian Campbell wrote:
>
>
> On Mon, Feb 9, 2015 at 3:59 PM, John Bradley <[email-masked]
> <mailto:[email-masked]>> wrote:
>

Yeah, and it looks like you can use it for anything.  It only defines 
default modes for various response types (code, token, etc.)

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Feb 2015 11:00:59 -0300

The code and implicit response_type are defined in RFC 6749.  
https://tools.ietf.org/html/rfc6749#section-4.1.2
https://tools.ietf.org/html/rfc6749#section-4.2.2

It describes one way to encode the response in each case with no mention of that being extended.   In the text there is no normative MUST.

I personally think changing the encoding of code via response_mode might be a technical violation of RFC 6749,  it will defiantly cause interop problems.

The multiple response type spec restates the defaults from RFC 6749, but doesn't explicitly say that you can change them with response_mode.

In Connect we were careful not to override anything in RFC 6749.

In your deployment using response_mode with code might work perfectly fine.  
Interop problems by implementations not expecting response_mode with the code response_type are the only real concern.

John B.

> On Feb 10, 2015, at 10:35 AM, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> Yeah, and it looks like you can use it for anything.  It only defines default modes for various response types (code, token, etc.)
> 
> -- 
> Bill Burke

---

From: Bill Burke <[email-masked]>
Date: Tue, 10 Feb 2015 09:27:24 -0500

> code_challenge_method=S256

Excellent.  Thanks.

> In Connect the JS client crates a nonce value and sends that with the request.  That value comes back in the signed_id token allowing the JS to know that the code and id_token are in reply to it's…

Why would you need the nonce if the IDP guarantees that the code can 
only be used once?  The code, state, and redirect-uri are all validated 
by the IDP with the access token request.

Bill

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Feb 2015 11:49:33 -0300

The nonce allows the client to insert a unique value into the id_token  to associate it with a particular browser session(Think SAML RequstID).   
That is useful for web server based clients.  It may or may not be useful in the JS case, as the client is the browser.

While code can only be used once, that doesn't stop someone from  intercepting a code/id_token from one session and replaying it in a different one to the same client.   

In the JS client case that would require a man in the middle between the browser and the AS, so is much harder for an attacker than the case where the client is a web server.

Using the PKCE code_challenge also lets the client detect if some substitution of the code has happened.

John B.
> On Feb 10, 2015, at 11:27 AM, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> Why would you need the nonce if the IDP guarantees that the code can only be used once?  The code, state, and redirect-uri are all validated by the IDP with the access token request.
> 
> Bill
> 
> -- 
> Bill Burke

---

From: Adam Lewis <[email-masked]>
Date: Tue, 10 Feb 2015 16:12:44 +0000

Hi John,

What do you mean by the app that is "already loaded and cached in the browser?"  Where did this app come from initially?  Is this what comes from the web-hosted client resource in step D/E of section 4.2?  So the first time D/E *will* flow over the wire, and in all subsequent requests it will be cached?

And with respect to the web hosted client resource, is this a resource deployed by the same domain as the RS to facilitate the deployment of user-agent-based apps to access the APIs exposed by that RS?

adam

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

The implicit flow doesn't depend on on the fragment not being re-appended to the resource location URI in the 302.  It would admittedly be more secure if that didn't happen.
Re-appending the fragment is the correct browser behaviour according to the W3C.

John B.

On Feb 9, 2015, at 6:21 PM, Prateek Mishra <[email-masked]<mailto:[email-masked]>> wrote:

- prateek

John B.

On Feb 9, 2015, at 5:50 PM, Bill Burke <[email-masked]><mailto:[email-masked]> wrote:

John B.

On Feb 9, 2015, at 5:05 PM, Bill Burke <[email-masked]><mailto:[email-masked]> wrote:

Hi Adam,

grant):

for a token)

point.)

Hope this helps,

  -Josh

<[email-masked]<mailto:[email-masked]>

<mailto:[email-masked]><mailto:[email-masked]>> wrote:

   Hi,____

   __ __

   __ __

   __ __

   redirect uri?____

   __ __

   trying to figure out what I'm missing?____

   __ __

   __ __

   __ __

   Tx!

   adam____

   OAuth mailing list

   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

Bill Burke

http://bill.burkecentral.com<http://bill.burkecentral.com/>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

Bill Burke

http://bill.burkecentral.com<http://bill.burkecentral.com/>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Feb 2015 14:10:07 -0300

Inline
> On Feb 10, 2015, at 1:12 PM, Adam Lewis <[email-masked]> wrote:
> 
> Hi John,
>  
> What do you mean by the app that is “already loaded and cached in the browser?”  Where did this app come from initially?  Is this what comes from the web-hosted client resource in step D/E of section 4.2?  So the first time D/E *will* flow over the wire, and in all subsequent requests it will be cached? 

Yes the web hosted client resource is typically the same JS code that is creating the Authorization request in A.   Now that you mention it the diagram in 4.2 is ambiguous about where that request comes from , the fact that it is coming from the browser implies that it is a JS CORS type request.

In some cases you might have a webserver invoke it via a 302 redirect and load a new JS app from the redirect URI.
 
The important thing is that the fragment is not sent to the server on the call that loads the JS even if it is not cached.  

The thing people do (facebook and others) that is twisting implicit in my opinion is having the callback URI just load a JS snipppet that extracts the token and posts it back to “Web hosted client resource”
Those applications should be using the code flow. 

> And with respect to the web hosted client resource, is this a resource deployed by the same domain as the RS to facilitate the deployment of user-agent-based apps to access the APIs exposed by that…

The hosted client resource is typically a AJAX/AngularJS application that doesn’t want to swap out it’s context by doing a full 302 redirect to the AS.  

The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps to protect the API that they use with OAuth, in that case they may all be from the same domain.

It might be that a sophisticated app may have multiple tokens for different API across multiple providers.

John B.
> On Feb 9, 2015, at 6:21 PM, Prateek Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Prateek Mishra <[email-masked]>
Date: Tue, 10 Feb 2015 10:45:11 -0800

We use a simpler flow that isn't as open-ended as the implicit flow.

The JS client uses a XMLHttpRequest call to exchange the browser cookie 
for an access token to the desired resource
(this can be modeled via the Assertion Framework specification, with the 
cookie acting as the authorization grant).

The JS client subsequently uses the access token to interact with the 
resource server.

- prateek
> Inline
>> On Feb 10, 2015, at 1:12 PM, Adam Lewis 
>> What do you mean by the app that is “already loaded and cached in the 
>> browser?”  Where did this app come from initially?  Is this what 
>> comes from the web-hosted client resource in step D/E of section 
>> 4.2?  So the first time D/E **will** flow over the wire, and in all 
>> subsequent requests it will be cached?
>
> Yes the web hosted client resource is typically the same JS code that 
> is creating the Authorization request in A.   Now that you mention it 
> the diagram in 4.2 is ambiguous about where that request comes from , 
> the fact that it is coming from the browser implies that it is a JS 
> CORS type request.
>
> In some cases you might have a webserver invoke it via a 302 redirect 
> and load a new JS app from the redirect URI.
> The important thing is that the fragment is not sent to the server on 
> the call that loads the JS even if it is not cached.
>
> The thing people do (facebook and others) that is twisting implicit in 
> my opinion is having the callback URI just load a JS snipppet that 
> extracts the token and posts it back to “Web hosted client resource”
>> And with respect to the web hosted client resource, is this a 
>> resource deployed by the same domain as the RS to facilitate the 
>> deployment of user-agent-based apps to access the APIs exposed by 
>> that RS?
>
> The hosted client resource is typically a AJAX/AngularJS application 
> that doesn’t want to swap out it’s context by doing a full 302 
> redirect to the AS.
>
> However it is not uncommon for people developing AngularJS apps to 
> protect the API that they use with OAuth, in that case they may all be 
> from the same domain.
>
>> *From:*OAuth [mailto:[email-masked]]*On Behalf Of*John Bradley
>> *Sent:*Monday, February 09, 2015 3:31 PM
>> *To:*Prateek Mishra
>> *Cc:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [OAUTH-WG] Confusion on Implicit Grant flow
>> Typically the implicit callback JS is part of the application that is 
>> already loaded and cached in the browser.
>> The implicit flow doesn’t depend on on the fragment not being 
>> re-appended to the resource location URI in the 302.  It would 
>> admittedly be more secure if that didn’t happen.
>> Implicit if done correctly has the token in one leg.  code on the 
>> other hand has the code in 4 legs and the token in one.
>> It is having the JS make the exchange of code for the AT without a 
>> secret that is the problem in my opinion.
>> If the client is a server that is doing the code -> token exchange 
>> then the answer is different, but the question was for a JS only client.
>> John B.
>>
>>     On Feb 9, 2015, at 6:21 PM, Prateek Mishra
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     The implicit flow depends upon a subtle and little known aspect
>>     of browser behavior - that the URI fragment component isn't
>>     propagated across redirects.
>>
>>     I havent checked this recently - but I am aware that several
>>     folks have found that some browser versions dont comply with this
>>     requirement.
>>     The additional round-trip issue is also unclear. The implicit
>>     flow requires an additional redirect (round-trip) to retrieve JS
>>     which retrieves the access token from the fragment URI.
>>
>>         On Feb 9, 2015, at 5:50 PM, Bill Burke<[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>           
>>
>>                 On Feb 9, 2015, at 5:05 PM, Bill Burke<[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>                   
>>

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 19 Feb 2015 11:14:06 +0000

I wonder if the spec would have contained POST + 307 response rather than a GET+302 with fragment for the implicit grant would have been safer…..

At least the risk of fragment leakage would have been lower...

regards

antonio

On Feb 10, 2015, at 6:10 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

Inline
On Feb 10, 2015, at 1:12 PM, Adam Lewis <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

John B.

adam

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow

John B.

- prateek

John B.

John B.

Hi Adam,

grant):

for a token)

point.)

Hope this helps,

  -Josh

   Hi,____

   __ __

   __ __

   __ __

   redirect uri?____

   __ __

   __ __

   __ __

   __ __

   Tx!

   adam____

   OAuth mailing list

OAuth mailing list

--

Bill Burke

OAuth mailing list

--

Bill Burke

OAuth mailing list