Subject: [OAUTH-WG] 2 Leg with OAuth 2.0

From: Brian Hawkins <[email-masked]>
Date: Tue, 29 Nov 2011 12:49:12 -0700

I'm having trouble finding information on how to do 2leg authentication
with OAuth 2.0.  Does it even support it?

Thanks
Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Nov 2011 12:53:34 -0700

> with OAuth 2.0.  Does it even support it?

This issue comes up often enough that it deserves to be in a FAQ.

Peter

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 Nov 2011 12:05:14 -0800

This diagram may be out of date, but I found it useful early on to understand the multiple flows and "legs" of OAuth.

http://www.independentid.com/2011/03/oauth-flows-extended.html

The question of "legs" (or parties as some prefer) depends on what you have and what you need.

Take a look at Implicit (4.2) and Resource Owner (4.3) flows for some examples of 2-leg flows using passwords. There are others for different types of grants.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-11-29, at 11:53 AM, Peter Saint-Andre wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Nov 2011 13:06:23 -0700

This functionality can be implemented in two main ways:

1.       Using the client credentials flow to get an access token, then using the protocol as usual

2.       Just using the Bearer (over SSL) or MAC token schemes without the rest of OAuth

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Hawkins
Sent: Tuesday, November 29, 2011 11:49 AM
To: [email-masked]
Subject: [OAUTH-WG] 2 Leg with OAuth 2.0

I'm having trouble finding information on how to do 2leg authentication with OAuth 2.0.  Does it even support it?

Thanks
Brian

---

From: Brian Campbell <[email-masked]>
Date: Tue, 29 Nov 2011 13:12:36 -0700

Or using the SAML or JWT grants to get an access token, then using the
protocol as usual.

---

From: Brian Hawkins <[email-masked]>
Date: Tue, 29 Nov 2011 13:27:49 -0700

Maybe I'm making this harder then it should be.

Here is the situation:  Site A and B both trust each other.  Site A needs
to update user information at site B.

With OAuth 1.0 Site A would use it's consumer key and secret to sign the
update call to Site B (no access token involved).  Only one message is sent.

The closest I can come to the above with OAuth 2.0 is to use the MAC token
scheme and sign the request with the consumer secret.  Is that valid?  I
kind of get the idea that the protocol doesn't care.

It feels like the bearer scheme just doesn't work for what I'm trying to do.

Thanks

Brian

On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> This functionality can be implemented in two main ways:****
>
> ** **
>
> **1.       **Using the client credentials flow to get an access token,
> then using the protocol as usual****
>
> **2.       **Just using the Bearer (over SSL) or MAC token schemes
> without the rest of OAuth****
>
> ** **
>
> EHL****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Hawkins
> *Sent:* Tuesday, November 29, 2011 11:49 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] 2 Leg with OAuth 2.0****
>
> ** **
>
> with OAuth 2.0.  Does it even support it?****
>
> ** **
>
> Thanks****
>
> Brian****
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Nov 2011 13:38:17 -0700

Both MAC and Bearer work in this setup, just think of them as HMAC-SHA-1 and PLAINTEXT in OAuth 1.0. In Bearer, your token is the client secret and in MAC, the client secret is the key.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Hawkins
Sent: Tuesday, November 29, 2011 12:28 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] 2 Leg with OAuth 2.0

Here is the situation:  Site A and B both trust each other.  Site A needs to update user information at site B.

With OAuth 1.0 Site A would use it's consumer key and secret to sign the update call to Site B (no access token involved).  Only one message is sent.

The closest I can come to the above with OAuth 2.0 is to use the MAC token scheme and sign the request with the consumer secret.  Is that valid?  I kind of get the idea that the protocol doesn't care.

Thanks

Brian
On Tue, Nov 29, 2011 at 1:06 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
This functionality can be implemented in two main ways:

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Hawkins
Sent: Tuesday, November 29, 2011 11:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] 2 Leg with OAuth 2.0

Thanks
Brian

---

From: William Mills <[email-masked]>
Date: Tue, 29 Nov 2011 12:59:09 -0800 (PST)

This isn't really OAuth, this is a trust relationship between A and B.  OAuth is providing an avenue for the user to approve access because the user owns the resource.  That's why this doesn't really fit what you are trying to do.

You could use MAC signatures to secure the transactions with a shared secret, sure.  Just decide on a single (or pair) of secrest to use in all cases one for the client and one for the "user" secret, which isn't really a user secret, it's your global shared secret.

-bill

________________________________
 From: Brian Hawkins <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Tuesday, November 29, 2011 12:27 PM
Subject: Re: [OAUTH-WG] 2 Leg with OAuth 2.0

Thanks

Brian

This functionality can be implemented in two main ways:
>From:[email-masked] [mailto:[email-masked]] On Behalf Of Brian Hawkins

---

From: William Mills <[email-masked]>
Date: Tue, 29 Nov 2011 13:00:26 -0800 (PST)

MAC would be more appropriate in my opinion for this.  

________________________________
 From: Eran Hammer-Lahav <[email-masked]>
To: Brian Hawkins <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, November 29, 2011 12:38 PM
Subject: Re: [OAUTH-WG] 2 Leg with OAuth 2.0

EHL

 

 
 
Thanks
 
Brian

EHL

 
Thanks
Brian