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 gr
Inline
> On Feb 10, 2015, at 1:12 PM, Adam Lewis
> 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
Does https://tools.ietf.org/html/draft-ietf-oauth-spop-10 provide a way for us
to replace the implicit flow with the code+proof key model? Yes, Implicit
saves a round trip. This does deal nicely with some of the security concerns
raised recently around how fragments are handled in the browser.
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
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 o
On 2/10/2015 8:15 AM, John Bradley wrote:
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 ext
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 M
On 2/10/2015 7:06 AM, Brian Campbell wrote:
On Mon, Feb 9, 2015 at 3:59 PM, John Bradley mailto:ve7...@ve7jtb.com>> wrote:
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. Th
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 loggin
On Mon, Feb 9, 2015 at 3:59 PM, John Bradley wrote:
> 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://o
Hi John
On 09/02/15 22:59, John Bradley wrote:
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, a
11 matches
Mail list logo
