Download the PHP package dingo/oauth2-server without Composer

PHP OAuth 2.0 Server

A PHP OAuth 2.0 server implementation.

Installation

The package can be installed with Composer, either by modifying your composer.json directly or using the composer require command.

Note that this package is still under development and has not been tagged as stable.

Grant Types

All four OAuth 2.0 grant types detailed in the specification are implemented within this package.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

Storage Adapters

As of v0.1.0 the following storage adapters are available.

• Dingo\OAuth2\Storage\MySqlAdapter
• Dingo\OAuth2\Storage\RedisAdapter

Using the dingo/oauth2-server-laravel package you also have.

• Dingo\OAuth2\Storage\FluentAdapter

MySQL Table Structure

The following is the table structure required for the MySQL storage adapter. When developing your own storage adapters you can use this structure as a starting point.

Usage Guide

This guide is very brief and is framework agnostic. It's purpose is to simply demonstrate how the pieces come together and is not meant to be used as a real world implementation. As such there will be no mention of where each piece of code belongs.

Before we continue you should be aware of what the following terms mean.

Clients

In OAuth 2.0 a client is an application that acts on behalf of a user and talks to the Authorization and Resource servers.

The package is capable of creating clients, however, no user interface is provided with the package. To create a client you'll need a storage adapter instance.

You can now get the client storage and create a new client.

A client is expected to have at least ONE associated endpoint and it should be defined as the default endpoint. Clients can have multiple endpoints for testing or staging servers.

A client can be set as "trusted", meaning you can perform a quick check before authorizing and if the client is marked as "trusted" then it will be automatically authorized. The fifth parameter must be set to true to mark the client as "trusted".

You can also delete a client. This will also delete an associated endpoints.

For the rest of the guide it will be assumed that you have created a client similar to the following.

Scopes

When a client requests a users authorization the client will often request specific permissions, these permissions are refered to as a scope. A scope defines what the client has permission to see or do. Essentially they provide developers with even finer control over what a client can access.

The package is capable of creating scopes, however, no user interface is provided with the package. To create a scope you'll need a storage adapter instance.

You can now get the scope storage and create a new scope.

You can also delete a scope.

This guide will not utilize scopes, however, feel free to create and use them.

Authorization Server

The responsibilities of the Authorization Server are to authorize and issue access tokens to clients. Depending on the configuration the Authorization Server will also issue a refresh token which the client should store for when the access token expires.

To issue an access token the Authorization Server must be configured with the desired storage adapter and grant types.

We can now register the four different grant types depending on the projects requirements. For this guide we'll only be using the standard Authorization Code grant type.

We'll now need a route that will handle the attempted authorization. This guide will assume this route is at http://localhost/example-server/authorize.

The client can now prompt a user to authorize via OAuth 2.0 by directing the user to a similar URI as follows (note that spacing has been added for readability).

If the Authorization Server detects that the user is not logged in they will be redirected to the login page and requested to login. Once logged in the user should be redirected back where they are prompted to authorize the client unless the client has been marked as "trusted". If the user authorizes the client the Authorization Server will issue an authorization code which is sent back as part of the query string on the redirect URI that was provided.

Remember that if a redirection URI is provided it must match a redirection URI that was registered for the client. When no redirection URI is provided the default redirection URI is used.

Now that the client has the authorization code it needs to request an access token from the Authorization Server using the code. We'll need a route that will handle the issuing of access tokens. This guide will assume the route is at http://localhost/example-server/token.

The client can now request the access token by sending another request to the Authorization Server to a similar URI as follows (note that spacing has been added for readability).

The Authorization Server should respond with a JSON payload similar to the following.

The client should save the refresh token and all subsequent requests to protected resources should include an Authorization header similar to the following.

Authorized Callback

You can set an optional authorized callback that is fired once a client has been authorized. This is useful for when you want to avoid prompting a user to authorize a client that they've already authorized in the past with the same scopes. The callback receives two parameters, the first being an instance of Dingo\OAuth2\Entity\Token and the second being an instance of Dingo\OAuth2\Entity\Client.

It's up to you to implement the code required to check if the user has already authorized the client in the past. As an example you might adjust the if statement earlier to check the existence of a database record.

Be sure to only authorize requests that have the same scopes or less. Never authorize a request that includes different scopes as the user should be give the chance the review and either approve or deny the request.

Resource Server

The responsibility of the Resource Server is to authenticate a request by validating the supplied access token.

We can now validate that a request contains an access token that exists and has not expired.

Exception Errors

When issuing access tokens or validating requests for a protected resource exceptions may be thrown when something goes wrong, e.g., missing a required parameter in the request. Generally speaking all exceptions thrown will extend from Dingo\OAuth2\Exception\OAuthException. Each exception will have an error type, a message, and an HTTP status code.

This allows you to return more informative responses to clients. Returning both the error type and error message is convenient for clients to distinguish what actually happened and react accordingly.

Refer to the Resource Server example above to see how exceptions should be caught and returned to the client.

Error Types

The following tables describes the error types and the reason as to why this error was raised.