Download the PHP package kamermans/guzzle-oauth2-subscriber without Composer

On this page you can find all versions of the php package kamermans/guzzle-oauth2-subscriber. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package guzzle-oauth2-subscriber

Guzzle OAuth 2.0 Subscriber

Tested with Guzzle 4, 5, 6, 7 and PHP 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 and 8.1.

This is an OAuth 2.0 client for Guzzle which aims to be 100% compatible with Guzzle 4, 5, 6, 7 and all future versions within a single package. Although I love Guzzle, its interfaces keep changing, causing massive breaking changes every 12 months or so, so I have created this package to help reduce the dependency hell that most third-party Guzzle dependencies bring with them. I wrote the official Guzzle OAuth 2.0 plugin which is still on the oauth2 branch, over at the official Guzzle repo, but I see that they have dropped support for Guzzle < v6 on master, which prompted me to split this back off to a separate package.

Features

Installation

This project can be installed using Composer. Run composer require kamermans/guzzle-oauth2-subscriber or add the following to your composer.json:

Usage

This plugin integrates seamlessly with Guzzle, transparently adding authentication to outgoing requests and optionally attempting re-authorization if the access token is no longer valid.

There are multiple grant types available like PasswordCredentials, ClientCredentials and AuthorizationCode.

Guzzle 4 & 5 vs Guzzle 6+

With the Guzzle 6 release, most of the library was refactored or completely rewritten, and as such, the integration of this library is different.

Emitters (Guzzle 4 & 5)

Guzzle 4 & 5 use Event Subscribers, and this library includes OAuth2Subscriber for that purpose:

Middleware (Guzzle 6+)

Starting with Guzzle 6, Middleware is used to integrate OAuth, and this library includes OAuth2Middleware for that purpose:

Alternatively, you can add the middleware to an existing Guzzle Client:

Client Credentials Example

Client credentials are normally used in server-to-server authentication. With this grant type, a client is requesting authorization in its own behalf, so there are only two parties involved. At a minimum, a client_id and client_secret are required, although many services require a scope and other parameters.

Here's an example of the client credentials method in Guzzle 4 and Guzzle 5:

Here's the same example for Guzzle 6+:

Authorization Code Example

There is a full example of using the AuthorizationCode grant type with a RefreshToken in the examples/ directory.

Grant Types

The following OAuth grant types are supported directly, and you can always create your own by implementing kamermans\OAuth2\GrantType\GrantTypeInterface:

Each of these takes a Guzzle client as the first argument. This client is used to obtain or refresh your OAuth access token, out of band from the other requests you are making.

Request Signers

There are two cases where we need to sign an HTTP request: when adding client credentials to a request for a new access token, and when adding an access token to a request.

Client Credentials Signers

When requesting a new access token, we need to send the required credentials to the OAuth 2 server. Adding information to a request is called signing in this library.

There are two client credentials signers included in kamermans\OAuth2\Signer\ClientCredentials:

If the OAuth 2 server you are obtaining an access token from does not support the built-in methods, you can either extend one of the built-in signers, or create your own by implementing kamermans\OAuth2\Signer\ClientCredentials\SignerInterface, for example:

Access Token Signers

When making a request to a REST endpoint protected by OAuth 2, we need to sign the request by adding the access token to it. This library intercepts your requests, signs them with the current access token, and sends them on their way.

The two most common ways to sign a request are included in kamermans\OAuth2\Signer\AccessToken:

Note: Use of the QueryString signer is discouraged because your access token is exposed in the URL. Also, you should only connect to OAuth-powered services via HTTPS so your access token is encrypted in flight.

You can create a custom access token signer by implementing kamermans\OAuth2\Signer\AccessToken\SignerInterface.

Access Token Persistence

Note: OAuth Access tokens should be stored somewhere securely and/or encrypted. If an attacker gains access to your access token, they could have unrestricted access to whatever resources and scopes were allowed!

By default, access tokens are not persisted anywhere. There are some built-in mechanisms for caching / persisting tokens (in kamermans\OAuth2\Persistence):

If you want to use your own persistence layer, you should write your own class that implements TokenPersistenceInterface or use the ClosureTokenPersistence provider, which is described at the end of this section.

To enable token persistence, you must use the OAuth2Middleware::setTokenPersistence() or OAuth2Subscriber::setTokenPersistence() method, like this:

Closure-Based Token Persistence

There are plenty of cases where you would like to use your own caching layer to store the OAuth2 data, but there is no adapter included that works with your cache provider. The ClosureTokenPersistence provider makes this case easier by allowing you to define closures that handle the OAuth2 persistence data, as shown in the example below.

Note: The format of the token data is a PHP associative array. You can flatten the array with serialize() or json_encode() or whatever else you want before storing it, but remember to decode it back to an array in get() before returning it! Also, the above example is not very thread-safe, so if you have a high level of concurrency, you will need to find more atomic ways to handle this logic, or at least wrap things with try/catch and handle things gracefully.

Please see the src/Persistence/ directory for more information on persistence.

Manually Setting an Access Token

For a manually-obtained access token, you can use the NullGrantType and set the access token manually as follows:

Note that if the access token is not set using setAccessToken(), a kamermans\OAuth2\Exception\ReauthorizationException will be thrown since the NullGrantType has no way to get a new access token.

Using Refresh Tokens

Refresh tokens are designed to allow a server to request a new access token on behalf of a user that is not present. For example, if some fictional app Angry Rodents wants to post something to the social media site Grillbook on behalf of the user, John Doe, the Angry Rodents app needs an access token for Grillbook. When John Doe first installs this app, it redirects him to the Grillbook site to authorize the Angry Rodents app to post on his behalf, and the Angry Rodents app receives an access token and a refresh token in the process. Eventually the access token expires, but Angry Rodents cannot use the original method (redirecting the user to ask for permission) every time the token expires, so instead, it sends the refresh token to Grillbook, which returns a new access token (and possibly a new refresh token).

To use refresh tokens, you pass a RefreshToken grant type object as the second argument to OAuth2Middleware or OAuth2Subscriber. Normally refresh tokens are only used in the interactive AuthorizationCode grant type (where the user is present), but it is also possible to use them with the other grant types (this is discouraged in the OAuth 2.0 spec). For example, here we are using a refresh token with the ClientCredentials grant type:

When using a refresh token to request a new access token, the server may send a new refresh token in the response. If a new refresh token was sent, it will be saved, otherwise the old refresh token will be retained.


All versions of guzzle-oauth2-subscriber with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package kamermans/guzzle-oauth2-subscriber contains the following files

Loading the files please wait ....