Download the PHP package piv915/oauth2-client without Composer

OAuth 2.0 Client

This package makes it simple to integrate your application with OAuth 2.0 service providers.

We are all used to seeing those "Connect with Facebook/Google/etc." buttons around the internet, and social network integration is an important feature of most web applications these days. Many of these sites use an authentication and authorization standard called OAuth 2.0 (RFC 6749).

This OAuth 2.0 client library will work with any OAuth provider that conforms to the OAuth 2.0 standard. Out-of-the-box, we provide a GenericProvider that may be used to connect to any service provider that uses Bearer tokens (see example below).

Many service providers provide additional functionality above and beyond the OAuth 2.0 standard. For this reason, this library may be easily extended and wrapped to support this additional behavior. We provide links to all known provider clients extending this library (i.e. Facebook, GitHub, Google, Instagram, LinkedIn, etc.). If your provider isn't in the list, feel free to add it.

This package is compliant with PSR-1, PSR-2, PSR-4, and PSR-7. If you notice compliance oversights, please send a patch via pull request. If you're interesting in contributing to this library, please take a look at our contributing guidelines.

Requirements

The following versions of PHP are supported.

• PHP 5.5
• PHP 5.6
• PHP 7.0
• HHVM

Providers

A list of official PHP League providers, as well as third-party providers, may be found in the providers list README.

To build your own provider, please refer to the provider guide README.

Usage

In most cases, you'll want to use a specific provider client library rather than this base library.

Take a look at README.PROVIDERS.md to see a list of provider client libraries.

If using Composer to require a specific provider client library, you do not need to also require this library. Composer will handle the dependencies for you.

Authorization Code Grant

The following example uses the out-of-the-box GenericProvider provided by this library. If you're looking for a specific provider (i.e. Facebook, Google, GitHub, etc.), take a look at our list of provider client libraries. HINT: You're probably looking for a specific provider.

The authorization code grant type is the most common grant type used when authenticating users with a third-party service. This grant type utilizes a client (this library), a server (the service provider), and a resource owner (the user with credentials to a protected—or owned—resource) to request access to resources owned by the user. This is often referred to as 3-legged OAuth, since there are three parties involved.

The following example illustrates this using Brent Shaffer's demo OAuth 2.0 application named Lock'd In. When running this code, you will be redirected to Lock'd In, where you'll be prompted to authorize the client to make requests to a resource on your behalf.

Now, you don't really have an account on Lock'd In, but for the sake of this example, imagine that you are already logged in on Lock'd In when you are redirected there.

Refreshing a Token

Once your application is authorized, you can refresh an expired token using a refresh token rather than going through the entire process of obtaining a brand new token. To do so, simply reuse this refresh token from your data store to request a refresh.

This example uses Brent Shaffer's demo OAuth 2.0 application named Lock'd In. See authorization code example above, for more details.

Resource Owner Password Credentials Grant

Some service providers allow you to skip the authorization code step to exchange a user's credentials (username and password) for an access token. This is referred to as the "resource owner password credentials" grant type.

According to section 1.3.3 of the OAuth 2.0 standard (emphasis added):

The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).

We do not advise using this grant type if the service provider supports the authorization code grant type (see above), as this reinforces the password anti-pattern by allowing users to think it's okay to trust third-party applications with their usernames and passwords.

That said, there are use-cases where the resource owner password credentials grant is acceptable and useful. Here's an example using it with Brent Shaffer's demo OAuth 2.0 application named Lock'd In. See authorization code example above, for more details about the Lock'd In demo application.

Client Credentials Grant

When your application is acting on its own behalf to access resources it controls/owns in a service provider, it may use the client credentials grant type. This is best used when the credentials for your application are stored privately and never exposed (e.g. through the web browser, etc.) to end-users. This grant type functions similarly to the resource owner password credentials grant type, but it does not request a user's username or password. It uses only the client ID and secret issued to your client by the service provider.

Unlike earlier examples, the following does not work against a functioning demo service provider. It is provided for the sake of example only.

Install

Via Composer

Contributing

Please see CONTRIBUTING for details.

License

The MIT License (MIT). Please see License File for more information.