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
