[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OAUTH-WG] Reevaluating Assumptions (Important!)



In addition to the use case James described, we use this to enable single sign on from a client/desktop app into a browser session. The client signs the URL and then opens the browser with that URL. The backend validates the signature and access token and then establishes an authentication session for the user.

A variant of this case is where a partner uses a back-channel federation call to authenticate their user to the AOL authentication service. A successful response includes an access token and secret (the equivalent of) which the partner can then user to sign an URL when their user invokes an AOL service (again providing SSO).

Thanks,
George

P.S. Documentation on this signed API call can be found here: http://dev.aol.com/authentication_for_clients#client2web

P.P.S. While these APIs are not OAuth specifically, the patterns are needed for OAuth compliant APIs to be developed

Eran Hammer-Lahav wrote:
Can you describe the actual use case?

EHL

-----Original Message-----
From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
Of Brian Eaton
Sent: Thursday, October 01, 2009 9:01 PM
To: George Fletcher
Cc: oauth at ietf.org
Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!)

On Thu, Oct 1, 2009 at 7:52 PM, George Fletcher <gffletch at aol.com>
wrote:
One use case (I think I saw it mentioned somewhere else on the list)
where
we've used the URI parameters is when we want the server to sign a
URL and
then pass that signed value to the browser to load. This can be done
with a
simple 302 and the signed URL. Switching to just supporting the
Authorization header will make this more difficult but probably not
impossible.
Yep.  I've seen that done multiple places.

One more unexpected use of OAuth...
_______________________________________________
OAuth mailing list
OAuth at ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.