Yahoo has exactly the same use case.
The user is authenticated into the Yahoo Instant Messenger client
application, and clicks on the Yahoo Mail button to check Yahoo Mail.
Clicking the Mail button spawns a browser window with an
authentication token that is passed to the browser on the URL. The
browser submits the token to Yahoo¹s authentication server which
validates the token, sets authentication cookies to the browser, and
then redirects the browser to Yahoo Mail.
Allen
On 4/8/10 11:30 AM, "George Fletcher" <[email protected]> wrote:
On 4/8/10 11:31 AM, Eran Hammer-Lahav wrote:
Re: [OAUTH-WG] Limiting signed requests to use the
Authorization request header 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
------------------------------------------------------------------------
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
