Download the PHP package zfr/zfr-oauth2-server without Composer

ZfrOAuth2Server

ZfrOAuth2Server is a PHP library that implements the OAuth 2 specification. It's main goal is to be a clean, PHP 7.0+ library that aims to be used with any persistence layer of choice. It is compatible with PSR-7 request and responses which makes it possible to use with any framework compatible with PSR-7.

Currently, ZfrOAuth2Server does not implement the whole specification (implicit grant is missing), so you are encouraged to have a look at the doc if ZfrOAuth2Server can be used in your application.

However, it implements the additional token revocation specification.

Here are other OAuth2 library you can use:

• OAuth2 Server from PHP-League
• OAuth2 Server from Brent Shaffer

Requirements

• PHP 7.4 or higher

To-do

• Write documentation
• Security audit
• Review of the whole spec
• Testing the authorization server more extensively
• Add implicit grant

Versioning note

Please note that until we reach 1.0, we WILL NOT follow semantic version. This means that BC can occur between 0.1.x and 0.2.x releases.

The current pre release of a completely rewritten version, is it not copatible with the previous implementation - which is considered EOL - see the legacy-0.7 branch.

See the CHANGELOG

Installation

use Composer to install:

Support

• File issues at https://github.com/zf-fr/zfr-oauth2-server/issues.
• Say hello in our gitter chat.

Configuration

Several Apache modules will strip HTTP authorization headers such as Authorization to try to enhance security by preventing scripts from seeing sensitive information unless the developer explicitly enables this.

Many of these modules will allow such headers if you simply add the following line to .htaccess (or the vhost directory directive).

since: Apache 2.4.13

Documentation

ZfrOAuth2Server is based on the RFC 6749 documentation.

Why use OAuth2?

OAuth2 is an authentication/authorization system that allows that can be used to:

• Implement a stateless authentication mechanism (useful for API)
• Allow third-party to connect to your application securely
• Securing your application through the use of scopes

OAuth2 is a dense, extensible specification that can be used for a wide number of use-cases. As of today, ZfrOAuth2Server implements three of the four official grants: AuthorizationGrant, ClientCredentialsGrant, PasswordGrant. Additionally a RefreshTokenGrant is provided to obtain new access tokens. ImplicitGrant and JWTTokens are forthcoming (help wanted).

How OAuth2 works?

This documentation does not aim to explain in details how OAuth2 work. Here is a nice resource you can read. However, here is the basic idea of how OAuth2 works:

1. A resource owner (your JavaScript API, your mobile application...) asks for a so-called "access token" to an authorization server. There are several strategies that depends on the use-case. Those strategies are called "grants". For instance, the "password grant" assumes that the resource owner sends its username/password. In all cases, your authorization server responds with an access token (and an optional refresh token).
2. The client sends this access token to each request that is made to your API. It is used by a "resource server" to map this access token to a user in your system.

Choosing the grant type depends on your application. Here are a few hints about which one to choose:

• If you are the only consumer of your API (for instance, your JavaScript application make calls to your API), you should use the "password grant". Because you trust your application, it is not a problem to send username/password.
• If you want a third-party code to connect to your API, and that you are sure that this third-party can keep secrets (this means the client is not a JavaScript API, or a mobile application): you can use the client credentials grant.
• If you want third-party code to connect to your API, and that those third-party applications cannot keep secret (think about an unofficial Twitter client that connect to your Twitter account, for instance), you should use the authorization grant.

Using the authorization server

The authorization server goal is to accept a request, and generate token. An authorization server can deny a request (for instance, if parameters are missing, or if username/password are incorrect).

To use an authorization server, you must first decide which grant you want to support. Some applications should only support one type of grant, others may support all of the available grant. This is completely up to you, and you should have a solid understanding of all those grants first. For instance, here is how you would create an authorization server that support the authorization only:

The request must be a valid Psr\Http\Message\ServerRequestInterface, and the authorization server returns a Psr\Http\Message\ResponseInterface object that is compliant with the OAuth2 specification.

Passing a user

Most of the time, you want to associate an access token to a user. This is the only way to map a token to a user of your system. To do this, you can pass an optional second parameter to the handleRequest. This class must implements the ZfrOAuth2\Server\Model\TokenOwnerInterface interface:

The AuthorizationServerMiddleware is able to do this for you and retrieve a user instance from a (configurable) request attribute. It is up to you to provide middleware which runs with a higher priority to add a TokenOwnerInterface instance to the request attribute.

Example of such a implementation which uses LaminasAuthentication and a TemplateRenderer from Mezzio.

Revoking a token

ZfrOAuth2Server supports revoking access and refresh tokens using the RFC 7009 specification. You can use the handleRevocationRequest method in the AuthorizationServer. You must pass the following two POST parameters:

• token: the token to remove (either access or refresh token)
• token_hint_type: must be either access_token or refresh_token to indicate the authorization server which token type to revoke.

If you need to revoke a token that was issued for a non-public client (this means a client that has a secret key), then you MUST authenticate the request using the client id and secret.

If you try to revoke a token that does not exist, it will return 200 SUCCESS request, according to the spec. However, if the token is valid, but cannot be deleted for any reason (database is down...), then it returns a 503 SERVICE UNAVAILABLE error!

Using the resource server

You can use the resource server to retrieve the access token (by automatically extracting the data from the HTTP headers). You can also specify scope constraints when retrieving the token:

The ResourceServerMiddleware is able to do this for you, simply have it run before any other middleware.

Example mezzio expressive route configuration.

Persistence layer

As of version 0.8-beta1 ZfrOAuth2Server has been rewritten to be persistence layer agnostic. Meaning it can by used with any prefered persistence layer.

Currently these packages provide a persistence layer;

• ZfrOAuth2ServerDoctrine for Doctrine 2