Subject: [OAUTH-WG] [Fwd: [oauth] Re: Oauth for 2 legged services]

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jun 2009 12:48:12 -0600

- -------- Original Message --------
Subject: 	[oauth] Re: Oauth for 2 legged services
Date: 	Tue, 23 Jun 2009 13:41:48 -0500
From: 	Josh Roesslein <[email-masked]>
Reply-To: 	[email-masked]
To: 	[email-masked]
References:
<[email-masked]>

On Tue, Jun 23, 2009 at 10:48 AM, ngw <[email-masked]
<mailto:[email-masked]>> wrote:

    Hi *, I'm trying to figure out how to implement OAuth for my own site,
    and something is still not completely clear.
    For example, I need to authenticate a certain class of users (site
    administrators) for a management interface. These users can see every
    kind of data and have read/write permissions on basically everything.
    Obviously, authentication and authorization is critical.
    This interface should basically authenticate against the main site
    with username and password and check for a given flag.

    If I understood OAuth correctly the workflow is
    1) The user points to foo.bar.com <http://foo.bar.com>
    2) foo.bar.com <http://foo.bar.com> contacts bar.com
    <http://bar.com> and asks the user to login in case the
    user isn't
    3) in case the credentials are right bar.com <http://bar.com> asks
    the user if the
    application foo.bar.com <http://foo.bar.com> can use his data, in
    case the credentials are
    wrong the user is redirected to a bar.com <http://bar.com> page
    4) foo.bar.com <http://foo.bar.com> queries the account of the user
    and checks if he is an
    administrator

What you describe here is a three legged flow. The two legged flow does
not perform an user
authentication with the SP. Instead we are just authenticating the
consumer with the SP. This consumer can represent
a single user or many, but to the SP its just one user. The consumer
authenticates with the SP by signing each
request with its shared secrete. The SP detects a two legged request by
the missing access token. It must then
verify the signature and identify the "user" by the consumer token. Two
legged is a good approach to use for instances where you don't care who
the user is or if the consumer is just a single user (ex. desktop app).

    Another question I have is what happens when the user connects after
    some time, is he already authenticated or it's just a matter to set
    some kind of expiration time for the token ?

With two legged the session would remain open until the SP disables the
consumer's secrete.
With three legged its up to the SP when to expire the access token.

I hope this helps clear things up for you. Good luck.

Josh

- --~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "OAuth" group.
To post to this group, send email to [email-masked]
To unsubscribe from this group, send email to
[email-masked]
For more options, visit this group at
http://groups.google.com/group/oauth?hl=en
- -~----------~----~----~----~------~----~------~--~---

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jun 2009 12:50:21 -0600

<hat type='individual'/>

Oops. I meant to say that it would be very helpful to have a clear
explanation of these various "legged" scenarios in the OAuth workflow
specification.

Peter

On 6/23/09 12:48 PM, Peter Saint-Andre wrote:
> 
> 
> -------- Original Message --------
> --~--~---------~--~----~------------~-------~--~----~
> -~----------~----~----~----~------~----~------~--~---