Download the PHP package isigar/oauth2 without Composer

OAuth2 Provider

This repository is being developed and it's highly unstable.

Requirements

Drahak/OAuth2 requires PHP version 5.3.0 or higher. The only production dependency is Nette framework 2.0.x.

Installation & setup

The easist way is to use Composer

$ composer require drahak/oauth2:@dev

Then add following code to your app bootstrap file before creating container:

or register it in config.neon:

Neon configuration

• accessTokenLifetime - access token life time in seconds
• refreshTokenLifetime - refresh token life time in seconds
• authorizationCodeLifetime - authorization code life time in seconds
• storage - storage will switch between default NDB and dibi storage. You can use your storage for each storage part.

OAuth2

Abstract protocol flow

OAuth Roles

Client - the third-party application

This application wants to get user's data from Resource server, so it needs to get an access token.

Resource server - API

There is data which client wants. API server uses access token to access user's information.

Resource owner

Gives access to some portion of their account.

See also OAuth 2 Simplified and original specification

OAuth presenter

Presenter (IOAuthPresenter) that gives an access. In base it has 2 main methods, issueAccessToken and issueAuthorizationCode. Simple OAuth (Resource owner) presenter could looks like this:

Method issueAccessToken determines correct grant type from grant_type parameter. In case of error throws some OAuthException which can be handled by oauthError method in default implementation.

Action authorize is more complex. This is used for generating Authorization code (see below - Authorization code) but for Implicit grant type it's necessary to generate access token here. In case if user is not logged in, redirect user to some login page and then restore authorization request using backlink.

Grant types

Are determined by grant_type parameter. There is support of base grant types as defined in OAuth2 specification: Authorization Code, Implicit, Password, Client Credentials and Refresh token.

1. Authorization code

   This grant type is great for third-party applications which can secure client secret code.

To generate access token, you'll need to get authorization code first. You can obtain it from IOAuthPresenter by calling issueAuthorizationCode

Request for authorization code:

• [REQUIRED] response_type - you want to generate authorization code
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token
• [REQUIRED] redirect_uri - URL address whereto redirect in case of success or error
• [OPTIONAL] scope - specify the scope of access request

Authorization code response:

In any case (error or success) Resource owner redirects back to the client using redirect_uri with authorization code as a query parameter:

Or

Since you have authorization code you can make access token request (data provided as application/x-www-form-urlencoded)

Request for access token:

• [REQUIRED] grant_type - this parameter says OAuth to use Authorization code
• [REQUIRED] code - authorization code which you got from Resource owner
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token
• [REQUIRED] client_secret - client (e.g. application) secret key that requests for access token

Access token response

In case or error, provides JSON response:

2. Implicit

   Is used for browser-based (web) or mobile applications, where you can't secure client secret so yopu can't use it to obtain access token.

Request for access token:

• [REQUIRED] response_type - since you request access token from Resource owner, you must tell you want an access token (not authorization code)
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token
• [REQUIRED] redirect_uri - URL where to redirect in case of success or error
• [OPTIONAL] scope - specify the scope of access request

Access token response

Redirect to redirect_uri

In case or error, redirects to:

3. Password

   Is used for trusted (usually first-party) applications, where you completely trust client because you generate access token from real user credentials (username, password)

Request for access token:

• [REQUIRED] grant_type - Password grant type uses identifier (so unexpectedly) password
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token
• [REQUIRED] username - real user's username
• [OPTIONAL] password - real user's password

Access token response

In case or error:

4. Client credentials

   If application needs to get access token for their own account outside the context of any specific user this is probably the best way.

Request for access token:

• [REQUIRED] grant_type - Password grant type uses identifier (so unexpectedly) password
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token
• [REQUIRED] client_secret - client (e.g. application) secret key that requests for access token

Access token response

In case or error:

5. Refresh token

   Is used to restore (actually re-generate) access token without authentication process. Refresh token is provided with almost every grant type (excluding Implicit).

Request for refresh token:

• [REQUIRED] grant_type - Refresh token identifier
• [REQUIRED] refresh_token - refresh token itself, that you got from almost any access token
• [REQUIRED] client_id - client ID (e.g. application) that requests for access token

Access token response

In case or error: