Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

From: Paul Lindner <[email-masked]>
Date: Thu, 10 Jun 2010 08:24:00 -0700

Hi,

As I've been working through our oauth2 implementation I've noticed that
it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the
request parameters alone.   Based on some investigative at the Shindig
project it appears that the only standard way to to determine 1.0a vs 2.0 is
by checking for the oauth_signature_method parameter.  More info here:

https://issues.apache.org/jira/browse/SHINDIG-1361

Has anyone else considered this use case?  How did you solve it?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 08:44:17 -0700

The request is very different on the resource server. On the authorization server, why would you use the same endpoint?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Lindner
Sent: Thursday, June 10, 2010 8:24 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests

Hi,

As I've been working through our oauth2 implementation I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the request parameters alone.   Based on some investigative at the Shindig project it appears that the only standard way to to determine 1.0a vs 2.0 is by checking for the oauth_signature_method parameter.  More info here:

---

From: Paul Lindner <[email-masked]>
Date: Thu, 10 Jun 2010 09:41:31 -0700

I am talking about the resource server. Specifically I want to be able to
quickly determine if an incoming request is 1.0a vs 2.0.  And since this is
a library it can't make a lot of assumptions about the specific environment
it's running in.

At first I thought I would check the oauth_version parameter.  It turns out
the 1.0a spec says that it is optional.  The only one that is required for
1.0a is oauth_signature_method.

Sadly we're long past time to change the spec to optimize for this use-case.
 (It would have been better to have a parameter for oauth 2.0 that is
distinct from 1.0a)  At the very least this message will live on in the
mailing list archives -- at best we document the proper way to distinguish
between the two versions somewhere.

On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> The request is very different on the resource server. On the authorization
> server, why would you use the same endpoint?
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Paul Lindner
> *Sent:* Thursday, June 10, 2010 8:24 AM
> *To:* OAuth WG ([email-masked])
> *Subject:* [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
>
>
>
> Hi,
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 10 Jun 2010 10:38:35 -0700

I run into the same issue. In section "4.2. URI Query Parameter", it
would help if the parameter name, oauth_token, was different from
OAuth 1.

Marius

On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 10:42:21 -0700

But in that case, all the other oauth_* parameters are missing. It's trivial.

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Thursday, June 10, 2010 10:39 AM
> To: Paul Lindner
> Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
> 
> I run into the same issue. In section "4.2. URI Query Parameter", it would
> help if the parameter name, oauth_token, was different from OAuth 1.
> 
> Marius
> 
> 
> 
> > I am talking about the resource server. Specifically I want to be able
> > to quickly determine if an incoming request is 1.0a vs 2.0.  And since
> > this is a library it can't make a lot of assumptions about the
> > specific environment it's running in.
> > At first I thought I would check the oauth_version parameter.  It
> > turns out the 1.0a spec says that it is optional.  The only one that
> > is required for 1.0a is oauth_signature_method.
> > distinct from 1.0a)  At the very least this message will live on in
> > the mailing list archives -- at best we document the proper way to
> > distinguish between the two versions somewhere.
> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> >>
> >> The request is very different on the resource server. On the
> >> authorization server, why would you use the same endpoint?
> >>
> >>
> >>
> >> EHL
> >>
> >>
> >>
> >> As I've been working through our oauth2 implementation I've noticed
> >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based
> >> on the request parameters alone.   Based on some investigative at the
> >> Shindig project it appears that the only standard way to to determine
> >> 1.0a vs 2.0 is by checking for the oauth_signature_method
> parameter.  More info here:
> >>
> >>
> >>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 10 Jun 2010 10:53:10 -0700

> But in that case, all the other oauth_* parameters are missing. It's trivial.

An OAuth 1 filter will interpret this as broken OAuth 1 authentication.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 10 Jun 2010 10:54:10 -0700

Which is fine if it doesn't support 2.0.

EHL

> Sent: Thursday, June 10, 2010 10:53 AM
> To: Eran Hammer-Lahav
> Cc: Paul Lindner; OAuth WG ([email-masked])
> >> > I am talking about the resource server. Specifically I want to be
> >> > able to quickly determine if an incoming request is 1.0a vs 2.0.
> >> > And since this is a library it can't make a lot of assumptions
> >> > about the specific environment it's running in.
> >> > turns out the 1.0a spec says that it is optional.  The only one
> >> > that is required for 1.0a is oauth_signature_method.
> >> >  (It would have been better to have a parameter for oauth 2.0 that
> >> > is distinct from 1.0a)  At the very least this message will live on
> >> > in the mailing list archives -- at best we document the proper way
> >> > to distinguish between the two versions somewhere.
> >> >> As I've been working through our oauth2 implementation I've
> >> >> noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0 API
> >> >> calls based on the request parameters alone.   Based on some
> >> >> investigative at the Shindig project it appears that the only
> >> >> standard way to to determine 1.0a vs 2.0 is by checking for the
> >> >> oauth_signature_method

---

From: Paul Lindner <[email-masked]>
Date: Thu, 10 Jun 2010 10:54:36 -0700

If you're routing requests with a load balancer it's not so trivial.
Instead of a substring match you're talking about a regex with negative
lookahead matching -- that's why the presence of the signature param is
essential to distinguishing between 2.0/1.0a.

On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> would

---

From: Rob Richards <[email-masked]>
Date: Mon, 14 Jun 2010 12:05:42 -0400

Wouldn't it make sense to require the oauth_version parameter under 2.0 
for resource calls so that the two versions can be distinguished?

Rob

Paul Lindner wrote:
> Instead of a substring match you're talking about a regex with 
> negative lookahead matching -- that's why the presence of the 
> signature param is essential to distinguishing between 2.0/1.0a.
>
> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > From: Marius Scurtescu [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > Cc: Eran Hammer-Lahav; OAuth WG ([email-masked]
>     <mailto:[email-masked]>)
>     > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > <[email-masked] <mailto:[email-masked]>>
>     > > wrote:
>     > >>
>     > >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > >> Behalf Of Paul Lindner
>     > >> To: OAuth WG ([email-masked] <mailto:[email-masked]>)
>     noticed
>     > > [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: David Recordon <[email-masked]>
Date: Mon, 14 Jun 2010 13:09:24 -0700

It's easy to detect version when calling a protected resource. In
OAuth 2.0 you only have one token parameter whereas 1.0 has a variety
of parameters including a signature.

--David

On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards <[email-masked]> wrote:
> Wouldn't it make sense to require the oauth_version parameter under 2.0 for
> resource calls so that the two versions can be distinguished?
>
> Rob
>
> Paul Lindner wrote:
>>
>> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>    > -----Original Message-----
>>    > From: Marius Scurtescu [mailto:[email-masked]
>>    > Sent: Thursday, June 10, 2010 10:39 AM
>>    > To: Paul Lindner
>>    > Cc: Eran Hammer-Lahav; OAuth WG ([email-masked]
>>    <mailto:[email-masked]>)
>>    > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
>>    >
>>    > I run into the same issue. In section "4.2. URI Query
>>    Parameter", it would
>>    > help if the parameter name, oauth_token, was different from OAuth 1.
>>    >
>>    > Marius
>>    >
>>    >
>>    >
>>    > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <[email-masked]
>>    > > I am talking about the resource server. Specifically I want to
>>    be able
>>    > > to quickly determine if an incoming request is 1.0a vs 2.0.
>>     And since
>>    > > this is a library it can't make a lot of assumptions about the
>>    > > specific environment it's running in.
>>    > > At first I thought I would check the oauth_version parameter.  It
>>    > > turns out the 1.0a spec says that it is optional.  The only
>>    one that
>>    > > is required for 1.0a is oauth_signature_method.
>>    > > Sadly we're long past time to change the spec to optimize for
>>    this use-case.
>>    > >  (It would have been better to have a parameter for oauth 2.0
>>    that is
>>    > > distinct from 1.0a)  At the very least this message will live
>>    on in
>>    > > the mailing list archives -- at best we document the proper way to
>>    > > distinguish between the two versions somewhere.
>>    > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav
>>    > > <[email-masked] <mailto:[email-masked]>>
>>    > > wrote:
>>    > >>
>>    > >> The request is very different on the resource server. On the
>>    > >> authorization server, why would you use the same endpoint?
>>    > >>
>>    > >>
>>    > >>
>>    > >> EHL
>>    > >>
>>    > >>
>>    > >>
>>    > >> From: [email-masked] <mailto:[email-masked]>
>>    > >> Behalf Of Paul Lindner
>>    > >> Sent: Thursday, June 10, 2010 8:24 AM
>>    > >> To: OAuth WG ([email-masked] <mailto:[email-masked]>)
>>    > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests
>>    > >>
>>    > >>
>>    > >>
>>    > >> Hi,
>>    > >>
>>    > >>
>>    > >>
>>    > >> As I've been working through our oauth2 implementation I've
>>    noticed
>>    > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API
>>    calls based
>>    > >> on the request parameters alone.   Based on some
>>    investigative at the
>>    > >> Shindig project it appears that the only standard way to to
>>    determine
>>    > >> 1.0a vs 2.0 is by checking for the oauth_signature_method
>>    > parameter.  More info here:
>>    > >>
>>    > >>
>>    > >>
>>    > >> https://issues.apache.org/jira/browse/SHINDIG-1361
>>    > >>
>>    > >>
>>    > >>
>>    > >> Has anyone else considered this use case?  How did you solve it?
>>    > >>
>>    > >>
>>    > >
>>    > > _______________________________________________
>>    > > OAuth mailing list
>>    > > [email-masked] <mailto:[email-masked]>
>>    > > https://www.ietf.org/mailman/listinfo/oauth
>>    > >
>>    > >
>>
>>

---

From: Paul Lindner <[email-masked]>
Date: Mon, 14 Jun 2010 13:46:24 -0700

As stated previously the easy way to determine OAuth 1.0 vs 2.0 without
using negative assertions is to check for the presence of
oauth_signature_method

On Mon, Jun 14, 2010 at 1:09 PM, David Recordon <[email-masked]> wrote:

> for

---

From: Rob Richards <[email-masked]>
Date: Mon, 14 Jun 2010 17:12:27 -0400

Both of those scenarios could also be bad 1.0 calls where a 400 error 
needs to be thrown due to missing a required parameter.
So worse case is that every single parameter from a 1.0 calls needs to 
be checked that at least one of them exists in the call and then its 
still possible that it could be a bad 1.0 although it looks like 2.0.

Rob

Paul Lindner wrote:
> As stated previously the easy way to determine OAuth 1.0 vs 2.0 
> without using negative assertions is to check for the presence of 
> oauth_signature_method
>
> On Mon, Jun 14, 2010 at 1:09 PM, David Recordon <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     negative
>     <[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     <mailto:[email-masked]>
>     >>    <mailto:[email-masked] <mailto:[email-masked]>>]
>     <mailto:[email-masked]>
>     >>    <mailto:[email-masked] <mailto:[email-masked]>>)
>     >>    > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner
>     <[email-masked] <mailto:[email-masked]>
>     >>    <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>    > > I am talking about the resource server. Specifically I
>     want to
>     >>    be able
>     >>    > > Sadly we're long past time to change the spec to
>     optimize for
>     >>    this use-case.
>     >>    > >  (It would have been better to have a parameter for
>     oauth 2.0
>     >>    that is
>     >>    > > distinct from 1.0a)  At the very least this message will
>     live
>     >>    on in
>     >>    > > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>    > > wrote:
>     >>    > >>
>     >>    > >> From: [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>    [mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>] On
>     >>    > >> Behalf Of Paul Lindner
>     >>    > >> To: OAuth WG ([email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>)
>     <mailto:[email-masked] <mailto:[email-masked]>>