search

songkick / oauth2-provider

Simple OAuth 2.0 provider toolkit
MIT License
528 stars 148 forks source link

Allow OAuth clients using more recent draft versions to work as well #44

Closed wvengen closed 12 years ago

wvengen commented 12 years ago

In older OAuth drafts, the method used in the Authorization HTTP header was OAuth; in more recent drafts, this changed to Bearer. To make more recent clients just work with this provider, it makes sense to accept both.

jcoglan commented 12 years ago

We are not upgrading this library to a more recent draft until the spec is finalized, or unless there is a pressing security reason to do so. Mixing features from various drafts only makes it harder to reason about the behaviour of the library since there's no one document you can point to that describes it.

If you fork the library and update it to a recent draft, you should make sure the library implements only that draft and nothing else.

wvengen commented 12 years ago

Thanks for your fast response! I'm working on OAuth clients and find that having to cater for multiple draft versions complicates client configuration for developers using these clients. But I can see sense in waiting for the spec progressing from draft status.

jcoglan commented 12 years ago

The thing is, if a client wants to use Bearer (introduced in draft 12), it will also want to use other semantics that only exist in or since 12 (e.g. pluggable token types, extensions instead of assertions, access_token vs oauth_token, etc.), and the server needs to support those semantics to make the client happy. Having a mix of features makes things more complicated for both parties.