Shah; Oleg Gryb; OAuth WG
Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
From what has been discussed in this thread (and other discussions before), I
see the need for the following variants:
- code in URI (Web App.)
- token in fragment (JS client app)
- code in fragment (installed app
n
> > To: Oleg Gryb
> > Cc: Naitik Shah ; OAuth WG
> > Sent: Wed, August 11, 2010 11:03:12 AM
> > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
> >
> > On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote:
> > > The thing is that each time whe
- Original Message
> From: Brian Eaton
> To: Oleg Gryb
> Cc: Naitik Shah ; OAuth WG
> Sent: Wed, August 11, 2010 11:03:12 AM
> Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
> On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote:
> > The thi
On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote:
> The thing is that each time when a web app with sensitive info can be run in
> a frame, security people would advice to break that
> frame-reads-other-frame-data logic, because it can lead to violation of same
> origin policy.
This is incorrect
From what has been discussed in this thread (and other discussions before), I
see the need for the following variants:
- code in URI (Web App.)
- token in fragment (JS client app)
- code in fragment (installed app)
- code in URI + token in fragment (Web App. with JS Client?)
Any comments?
regar
t: Tuesday, August 10, 2010 1:19 PM
To: Oleg Gryb
Cc: Luke Shepard; Torsten Lodderstedt; Naitik Shah; OAuth WG
Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
Hey Oleg, a server based "safer" version of the user agent flow is the
web server flow. It doesn't pass the access toke
Lodderstedt ; David Recordon
> ; Naitik Shah ; OAuth WG
>
> Sent: Tue, August 10, 2010 10:23:56 AM
> Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
> Here are the possible URLs:
> http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzi
cordon
>; Naitik Shah ; OAuth WG
>
>Sent: Tue, August 10, 2010 10:23:56 AM
>Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
>
>Here are the possible URLs:
>
>
>http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzipa3p
>
Thank you for the explanation.
I now understand that the fragment is used for efficiently passing token or
code on the client side. What I still don't understand is why a client would
need both at once (url 1)? Have you such applications in production?
regards,
Torsten.
Am 10.08.2010 um 19:
Thank you for the explanation. I no
Am 10.08.2010 um 19:23 schrieb Luke Shepard :
> Here are the possible URLs:
>
> http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzipa3p
> http://static.facebook.com/connect/xd_proxy.php?code=10alkji#access_token=lzipa3p
>
> Those w
Here are the possible URLs:
http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzipa3p
http://static.facebook.com/connect/xd_proxy.php?code=10alkji#access_token=lzipa3p
Those who already use this flow in production (including Google, Facebook,
Twitter, and others) typicall
I was trying to understand that too (see "Is user agent profile secure"
thread).
The answers that I've got were:
1. It's already coded this way.
2. It's the most efficient way of doing that, because that relay.html page is
static and can be cached by a browser.
None of the answers above looks
Can someone pls. explain why code and token should both be returned in the
fragment?
regards,
Torsten.
Am 09.08.2010 um 20:32 schrieb David Recordon :
> The thread wondered a bit but Brian's summary here seems to be what most
> people were advocating for. Is there enough consensus to have Draf
me too
On Aug 9, 2010, at 12:59 PM, Luke Shepard wrote:
> I like Brian's solution.
>
> On Aug 9, 2010, at 11:32 AM, David Recordon wrote:
>
>> The thread wondered a bit but Brian's summary here seems to be what most
>> people were advocating for. Is there enough consensus to have Draft 11
>>
I like Brian's solution.
On Aug 9, 2010, at 11:32 AM, David Recordon wrote:
The thread wondered a bit but Brian's summary here seems to be what most people
were advocating for. Is there enough consensus to have Draft 11 reflect it?
Thanks,
--David
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton
The thread wondered a bit but Brian's summary here seems to be what most
people were advocating for. Is there enough consensus to have Draft 11
reflect it?
Thanks,
--David
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote:
> I can't parse this diagam, but here's my take:
>
> - web server flo
Am 15.07.2010 08:25, schrieb Brian Eaton:
On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
wrote:
why that? If there will be a signature proposal for resource server access,
the same (simplified?) model could be applied to the authz server's API.
Sure. Other folks have used si
On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
wrote:
> why that? If there will be a signature proposal for resource server access,
> the same (simplified?) model could be applied to the authz server's API.
Sure. Other folks have used signed URLs in this kind of protocol as
well: http://d
why that? If there will be a signature proposal for resource server
access, the same (simplified?) model could be applied to the authz
server's API.
And as I pointed out in my original posting, I see this as a _further_
option not the only one. While it is technically more complicated, it
has i
We implement the second option in our SSO protocol.
Am 15.07.2010 um 01:02 schrieb Brian Eaton :
> On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
> wrote:
>>> The second request (as you pointed out in your original mail) is
>>> currently used to verify the client identity. Do you have
On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
wrote:
>> The second request (as you pointed out in your original mail) is
>> currently used to verify the client identity. Do you have a
>> suggestion for an alternate mechanism?
>>
>
> A digital signature over the authz request? Alternatively
a - code in fragment
b - token in query
c - code and token in query
d - code and token split -10
EHL
On Jul 14, 2010, at 8:10, Eran Hammer-Lahav wrote:
> Please answer this based on actual use cases. When returning parameters
> using the redirection URI call, which of these combinations make
At some point this brings us back to 1.0...
EHL
On Jul 14, 2010, at 17:59, Torsten Lodderstedt wrote:
> Am 14.07.2010 23:52, schrieb Brian Eaton:
>> On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
>> wrote:
>>
>>> Yepp. That's an optimization of use case 2. That way the authz server d
I do not quite understand the combination table: what are a, b, and c
parameters?
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Wednesday, July 14, 2010 8:10 AM
To: OAuth WG
Subject: [OAUTH-WG] Quick survey
Am 14.07.2010 23:52, schrieb Brian Eaton:
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
wrote:
Yepp. That's an optimization of use case 2. That way the authz server does
not need to store the authorization transaction's results in a database and
there is no need to perform a a secon
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
wrote:
> Yepp. That's an optimization of use case 2. That way the authz server does
> not need to store the authorization transaction's results in a database and
> there is no need to perform a a second request.
The authorization server doesn't
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
wrote:
I would also like to see support for b. In this case, additional means for
client authentication should be considered.
b is token on query string?
What's the use case for that?
Yepp. That's an optimization of use case
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
wrote:
> I would also like to see support for b. In this case, additional means for
> client authentication should be considered.
b is token on query string?
What's the use case for that?
___
OAuth m
2 is a must have from my point of view.
I would also like to see support for b. In this case, additional means
for client authentication should be considered.
regards,
Torsten.
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of th
2 and 3 are practically most interesting imho.
(b) is interesting in that if a client application does have SSL, then it's
the simplest flow of all.
-Naitik
On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav wrote:
> Please answer this based on actual use cases. When returning parameters
> usi
I caught up on the thread and with Luke yesterday afternoon and am fine with
the user-agent flow using the fragment in the token and code case.
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote:
> I can't parse this diagam, but here's my take:
>
> - web server flow should always return just a
I can't parse this diagam, but here's my take:
- web server flow should always return just a code.
parameter always goes in the query string
it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh toke
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these combinations make sense?
| Code | Token | Code & Token
-+--+---+--
Fragment | a | 1 | 3
Query| 2 | b | c
Split* | n/a
33 matches
Mail list logo
