Latest commit 242e62f Jul 13, 2015 @fkooman update changes and spec

Build Status Scrutinizer Code Quality



This is an OAuth 2.0 Authorization Server written in PHP that is easy to integrate with your existing REST services, whether or not they are written in PHP. It will require minimal changes to your existing software.

Part of the development of this software was made possible by SURFnet.


  • Authorization code and implicit grant profile support
  • BasicAuthenication Backend (using username/password)
  • MellonAuthentication Backend (SAML)
  • PDO database backend support
  • Token introspection for resource servers
  • Management interfaces to manage client registration and authorized clients


The prefered method of installation is to use the RPM packages. The RPM packages can for now be found in the repository. For setting up a development environment, see below.

To enable the repositories on Fedora do the following:

$ sudo yum -y install yum-plugin-copr
$ yum copr enable -y fkooman/php-base
$ yum copr enable -y fkooman/php-oauth
$ yum install -y php-oauth-as

Restart Apache:

$ sudo service httpd restart

You can now configure the OAuth server in /etc/php-oauth-as/oauth.ini. After this is done you can initialize the database.

$ sudo -u apache php-oauth-as-initdb

Development Requirements

On Fedora/CentOS:

$ sudo yum install php-pdo php-openssl httpd'

You also need to download Composer.

The software is being developed on Fedora 21, but should run on CentOS 6 and CentOS 7 and should also work on RHEL 6 and RHEL 7.

Development Installation

NOTE: in the chown line you need to use your own user account name!

$ cd /var/www
$ sudo mkdir php-oauth-as
$ sudo chown fkooman.fkooman php-oauth-as
$ git clone
$ cd php-oauth-as
$ /path/to/composer.phar install
$ mkdir data
$ sudo chown apache.apache data
$ sudo semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/php-oauth-as/data(/.*)?'
$ sudo restorecon -R /var/www/php-oauth-as/data
$ cp config/oauth.ini.defaults config/oauth.ini

Edit oauth.ini to match the configuration. You need to at least modify the following line, and set it to the value shown here:

dsn = "sqlite:/var/www/php-oauth-as/data/db.sqlite"

Now initialize the database:

$ sudo -u apache bin/php-oauth-as-initdb 

Copy paste the contents of the Apache section in the file /etc/httpd/conf.d/php-oauth-as.conf:

Alias /php-oauth-as /var/www/php-oauth-as/web

<Directory /var/www/php-oauth-as/web>
    AllowOverride None

    Require local
    #Require all granted

    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

Now restart Apache:

$ sudo service httpd restart

If you ever remove the software, you can also remove the SELinux context:

$ sudo semanage fcontext -d -t httpd_sys_rw_content_t '/var/www/php-oauth-as/data(/.*)?'


The templates in the views folder can be copied to the config/views folder and overridden that way. If you install through the RPM package you can copy the files from /usr/share/php-oauth-as/views to /etc/php-oauth-as/views and modify them there. There you can also update them to point to a different CSS file for example.


There ares some plugins provided for user authentication:

  • BasicAuthentication - Simple static username/password authentication configured through config/oauth.ini (DEFAULT)
  • MellonAuthentication - Plugin for SAML authentication

You can configure which plugin to use by modifying the authenticationPlugin setting in config/oauth.ini.

You do need to configure these authentication backends separately. See the respective documentation for those projects.


In order to delete stale tokens a housekeeping script is available, php-oauth-as-housekeeping. It should be ran periodically using crontab(5) or a similar mechanism. For example, to run it every night 5 minutes after midnight use the following as a cron entry:

5 0 * * *     /usr/bin/php-oauth-as-housekeeping

When using SQlite this script should be run as the same user as the web server, or as root (NOT RECOMMENDED).

Resource Servers

If you are writing a resource server (RS) an API is available to verify the Bearer token you receive from the client. Currently a draft specification draft-richer-oauth-introspection is implemented to support this.

An example, the RS gets the following Authorization header from the client:

Authorization: Bearer 40da7666a9f76b4b6b87969a7cc06421

Now in order to verify it, the RS can send a request to the OAuth service:

$ curl -d 'token=40da7666a9f76b4b6b87969a7cc06421' https://localhost/php-oauth-as/introspect.php
    "active": true,
    "client_id": "2352ea44-612d-448b-be10-6e29562e5130",
    "exp": 1433112094,
    "iat": 1433108494,
    "iss": "localhost",
    "scope": "",
    "sub": "admin",
    "token_type": "bearer",
    "user_id": "admin"

This way the RS can figure out more about the resource owner who authorized the client. If you provide an invalid access token, the following response is returned:

    "active": false

If your service needs to provision a user, the field sub SHOULD to be used for that. The scope field can be used to determine the scope the client was granted by the resource owner.

A plugin for fkooman/rest, fkooman/rest-plugin-bearer is available to integrate with this OAuth 2.0 AS service using Composer. Or see the project site.


Licensed under the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This roughly means that if you use this software in your service you need to make the source code available to the users of your service (if you modify it). Refer to the license for the exact details.