League\OAuth2

Locked

In October 2014, I offered to take over as the project maintainer for the OAuth 2.0 Client package for The League of Extraordinary Packages. My goal as project maintainer is to facilitate the development of the package, providing code reviews of pull requests and architectural direction, and conforming the code to the League standards and best practices, all in preparation for a 1.0.0 release.

Ben’s Manifesto for League\OAuth2 1.0.0

The goal of the library should be to provide a full-fledged RFC 6749 compliant OAuth 2.0 client.

This includes supporting the following authorization types:

  • Authorization Code Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant
  • Client Credentials Grant
  • Extension Grants (through extension of this library—not internal to the library)

The library should provide an out-of-the-box provider that may be used with any OAuth 2.0 server that adheres to RFC 6749. This provider may be configured upon instantiation by passing all necessary endpoint URLs, etc. into the provider, and then calls for authorization and access tokens may be made to it (see also issue #179).

Third-party provider libraries may base themselves on this out-of-the-box default provider, or if they drift too far from the OAuth 2.0 specification, they may adhere to a provider interface. As each provider supports varying degrees of the OAuth 2.0 specification (for example: supporting only one or two authorization types, varying authentication schemes, disparate error responses, etc.), the library must provide easy extension to allow third party provider libraries the flexibility needed to target a variety of OAuth 2.0 servers, handling their responses however varied they may be.

Since OAuth 2.0 does not define access token types (i.e. Bearer, MAC), this library must also be flexible enough to be extended to provide support for different access token types.