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 protected]> 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: >> >> 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 protected] >> <mailto:[email protected]>> wrote: >> >> But in that case, all the other oauth_* parameters are missing. >> It's trivial. >> >> EHL >> >> > -----Original Message----- >> > From: Marius Scurtescu [mailto:[email protected] >> <mailto:[email protected]>] >> > Sent: Thursday, June 10, 2010 10:39 AM >> > To: Paul Lindner >> > Cc: Eran Hammer-Lahav; OAuth WG ([email protected] >> <mailto:[email protected]>) >> > 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 protected] >> <mailto:[email protected]>> wrote: >> > > 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 protected] <mailto:[email protected]>> >> > > wrote: >> > >> >> > >> The request is very different on the resource server. On the >> > >> authorization server, why would you use the same endpoint? >> > >> >> > >> >> > >> >> > >> EHL >> > >> >> > >> >> > >> >> > >> From: [email protected] <mailto:[email protected]> >> [mailto:[email protected] <mailto:[email protected]>] On >> > >> Behalf Of Paul Lindner >> > >> Sent: Thursday, June 10, 2010 8:24 AM >> > >> To: OAuth WG ([email protected] <mailto:[email protected]>) >> > >> 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 protected] <mailto:[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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
