On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
Can you share an example of a native application launching an external
browser with a protect resource?
Native application = AIM
Protected Resource = User's AIM Mail box
AIM has supported this for a while.
Why can't the end user just login to the browser using normal web
login and access the resource?
It's a better user experience to be seamlessly logged in than having to
reenter credentials.
Thanks,
George
EHL
On 4/8/10 7:51 AM, "Anthony Nadalin" <[email protected]> wrote:
> Why is the native application launching a browser with a
protected resource request? That seems odd.
Not odd at all a lot of the Eclipse applications can work this way
*From:* [email protected] [mailto:[email protected]] *On
Behalf Of *Eran Hammer-Lahav
*Sent:* Thursday, April 08, 2010 7:41 AM
*To:* George Fletcher; OAuth WG
*Cc:* Jonathan Moore
*Subject:* Re: [OAUTH-WG] Limiting signed requests to use the
Authorization request header
Why is the native application launching a browser with a protected
resource request? That seems odd.
Note that we currently have no plans of supporting signatures in
any of the flows. We are discussing signatures only for using
tokens with secrets when accessing protected resources.
EHL
On 4/8/10 7:08 AM, "George Fletcher" <[email protected]> wrote:
Another use case is where a rich client wants to bootstrap a web
session with the same identity (rich client to web SSO). Assuming
that the web session will be established via OAuth with
signatures, there is no way to fire up the browser with a "signed
URL" if the OAuth parameters and signature need to be in a header.
As Jon mentions, the concept of allowing a service to create a
signed URL and then pass it back to JS running in the browser, or
invoking a browser directly is something that we leverage a lot
across our rich clients and web applications.
I realize that these sorts of use cases are trivial if
establishment of the SSO session switches from a signed mechanism
to the OAuth WRAP bearer token model. The one nice feature of the
signed URL is that it is one time use where the bearer token can
be replayed multiple times.
Thanks,
George
Real world use case. Login into the latest AIM client. Click the
mail icon/link.
On 3/31/10 7:25 AM, Moore, Jonathan wrote:
What about a use case where the signature will be generated by one
component but the request will be redeemed by another?
For example, suppose there is a cross-domain JSONP call that
requires authorization; in this case, I might have my client side
code hit *my* origin server, obtain a signed URL, and then redeem
it by hitting the JSONP resource. This has scaling advantages over
having my origin proxy an OAuth request, and doesn't require me to
have keys located on the client; I can keep them safely in my data
centers.
In this case, sending a "ready to redeem" signed request using the
query parameter mechanism simplifies the client-side code.
Furthermore, in this use case (cross-domain script inclusion), the
client doesn't have the means to set the Authorization header (it
can only include a <script> element with a URL).
A similar use case would be if you wanted to provide signed
redirects (similarly useful for cross-domain functionality);
browsers aren't going to modify the redirect URL they get back, or
add an Authorization header to it.
Jon
........
Jon Moore
Comcast Interactive Media
-----Original Message-----
From: [email protected] on behalf of Eran Hammer-Lahav
Sent: Wed 3/31/2010 12:20 AM
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the
Authorizationrequest header
Since we have consensus that using signed requests is a more
advance use
case and will be used by more experienced developer, I would like
to suggest
we limit sending signed request parameters to the Authorization
header (no
URI query parameters or form-encoded body).
This will not change the ability to send the oauth_token parameter
in the
query or body when using bearer tokens (as well as in the header).
It will
only apply to sending signed requests.
The makes client request parameter much simpler as the only parameter
"invading" the URI or body space of the request is oauth_token.
Anything
else is limited to the header.
Thoughts? If you are not a fan, please reply with a use case.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
