this is code Ouath2 Controller. I already include "zetacomponents/database": "1.4.6" in composer.json

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');

/**
* 
*/
class Oauth2 extends CI_Controller
{

    public function __construct()
    {
        parent::__construct();

        $this->load->library('session');
        $this->load->helper(array('url', 'form'));

        // Initiate the request handler which deals with $_GET, $_POST, etc
        $request = new League\OAuth2\Server\Util\Request();

        // Initiate a new database connection
        $db = new League\OAuth2\Server\Storage\PDO\Db('mysql://root:root@localhost/alex_oauth');

        // Create the auth server, the three parameters passed are references
        //  to the storage models
        $this->authserver = new League\OAuth2\Server\Authorization(
            new League\OAuth2\Server\Storage\PDO\Client($db),
            new League\OAuth2\Server\Storage\PDO\Session($db),
            new League\OAuth2\Server\Storage\PDO\Scope($db)
        );

        // Enable the authorization code grant type
        $this->authserver->addGrantType(new League\OAuth2\Server\Grant\AuthCode($this->authserver));
    }

    public function index()
    {
        try {

            // Tell the auth server to check the required parameters are in the
            //  query string
            $params = $this->authserver->getGrantType('authorization_code')->checkAuthoriseParams();

            // Save the verified parameters to the user's session
            $this->session->set_userdata('client_id', $params['client_id']);
            $this->session->set_userdata('client_details', $params['client_details']);
            $this->session->set_userdata('redirect_uri', $params['redirect_uri']);
            $this->session->set_userdata('response_type', $params['response_type']);
            $this->session->set_userdata('scopes', $params['scopes']);

            // Redirect the user to the sign-in route
            redirect('oauth2/signin');

        } catch (Oauth2\Exception\ClientException $e) {
            echo "error";
            // Throw an error here which says what the problem is with the
            //  auth params

        } catch (Exception $e) {
           // I ALWAYS IN HERE
            echo $e->getMessage();
            // Throw an error here which has caught a non-library specific error

        }
    }

    public function signin()
    {
        // Retrieve the auth params from the user's session
        $params['client_id'] = $this->session->userdata('client_id');
        $params['client_details'] = $this->session->userdata('client_details');
        $params['redirect_uri'] = $this->session->userdata('redirect_uri');
        $params['response_type'] = $this->session->userdata('response_type');
        $params['scopes'] = $this->session->userdata('scopes');

        // Check that the auth params are all present
        foreach ($params as $key=>$value) {
            if ($value == null) {
                // Throw an error because an auth param is missing - don't
                //  continue any further
            }
        }

        // Process the sign-in form submission
        if ($this->input->get_post('signin') != null) {
            try {

                // Get username
                $u = $this->input->get('username');
                if ($u == null || trim($u) == '') {
                    throw new Exception('please enter your username.');
                }

                // Get password
                $p = $this->input->get('password');
                if ($p == null || trim($p) == '') {
                    throw new Exception('please enter your password.');
                }

                // Verify the user's username and password
                // Set the user's ID to a session

            } catch (Exception $e) {
                $params['error_message'] = $e->getMessage();
            }
        }

        // Get the user's ID from their session
        $params['user_id'] = $this->session->userdata('user_id');

        // User is signed in
        if ($params['user_id'] != null) {

            // Redirect the user to /oauth/authorise route
            redirect('oauth2/authorize');

        }

        // User is not signed in, show the sign-in form
        else {
            echo "login form";
        }
    }
}

I get the following errors when trying to use both a PUT and DELETE request.

Call to undefined method League\OAuth2\Server\Util\Request::DELETE() Call to undefined method League\OAuth2\Server\Util\Request::PUT()

This happens if i pass the access_token as a parameter.

If it's an authorization header it's fine.

Now that v4 has been merged into develop branch I can work on the documentation.

This issue is for tracking new documentation which will be located at http://oauth2.thephpleague.com/

TODO:

• [x] Resource server
• [x] Auth code grant
• [x] Client credentials grant
• [x] Password grant
• [x] Refresh token
• [x] Creating your own grants
• [x] Subscribing to events
• [x] Creating your own token identifier generator
• [ ] Creating your own token types
• [ ] Integration with frameworks
• [ ] Upgrading from v3

My application just broke down when upgrading to 7.3.0, working fine still when downgrading to 7.2.0.

I'm using the following override in my custom OAuth2Server class to customize the response type:

    /**
     * {@inheritdoc}
     */
    protected function getResponseType()
    {
        $this->responseType = new ExtendedBearerTokenResponse(...someparameters);

        return parent::getResponseType();
    }

The extended response class overrides the default BearerTokenResponse in getExtraParams to add some extra properties to the token. This method is apparently not called anymore, or ignored, as the tokens no longer contain the extra properties.

Have an appointment in 5 minutes so no time to debug further right now, but posting this already hoping you may have an idea what's causing this and issue a fix before I can investigate deeper tomorrow.

Copies helper methods for exception handling from the Authorization server into the Resource server to allow for implementing RFC 6750, section 3.1:

• getExceptionType
• getExceptionMessage
• getExceptionHttpHeaders

Adds $required parameter to hasScope to trigger exceptions when scopes are missing from the session.

Adds two new exceptions, MissingAccessToken and InsufficientScope to differentiate between the different error responses from the resource server.

Tests updated and new tests written to complete code coverage.

On the implicit grant, how do I use newAuthoriseRequest() and checkAuthoriseParams() which exist only in AuthCode? I see only completeFlow() on the Implicit object.

As of now I have implemented the Implicit flow using the outdated AuthCode tutorial, so my last /authorise route actually takes the generated auth code and makes an access token out of it, which is returned to the user, instead of returning the auth code.

Right now, using the altered AuthCode grant for Implicit, my /authorise route looks like this:

$app->post('/authorise', function() use ($server, $app) {

        // Check the auth params are in the session
        if ( ! isset($_SESSION['authParams']))
        {
                throw new Exception('Missing auth parameters');
        }

        $params = $_SESSION['authParams'];

        // Check the user is signed in
        if ( ! isset($params['user_id']))
        {
                $app->redirect('/login');
        }

        // If the user approves the client then generate an authoriztion code
        if (isset($_POST['approve']))
        {
                $authCode = $server->getGrantType("authorization_code")->newAuthoriseRequest('user', $params['user_id'], $params);
                // echo '<p>The user authorised a request and so would be redirected back to the client...</p>';   
                //So far this is Authorisation Grant. Now we want to make it Implicit and return an access token staight ahead.
                header('Content-type: application/javascript');
                try {
                    $params["grant_type"] = "authorization_code";
                    $params["code"] = $authCode;
                    foreach ($params['client_details'] as $key => &$clientParam){
                        $params[$key] = $clientParam;
                    }
                    $acToken = $server->issueAccessToken($params);
                    echo json_encode($acToken);
                } catch (Exception $e) {
                // Show an error message
                echo json_encode(array('error' => $e->getMessage(), 'error_code' => $e->getCode()));
                }
        }
        // The user denied the request so send them back to the client with an error
        elseif (isset($_POST['deny']))
        {
                // echo '<p>The user denied the request and so would be redirected back to the client...</p>';
                // echo League\OAuth2\Server\Util\RedirectUri::make($params['redirect_uri'], array(
                //         'error' => 'access_denied',
                //         'error_message' => $server::getExceptionMessage('access_denied'),
                //         'state'        => $params['state']
                // ));
            echo json_encode(array( //error response as valid json
                         'error' => 'access_denied',
                         'error_message' => $server::getExceptionMessage('access_denied'),
                         'state'        => $params['state'])
            );
        }
});

From RFC 6749 Section 6 - Refreshing an Access Token:

The authorization server MAY issue a new refresh token, .... The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client.

Here is 2 points I have in mind:

1. Based on the use cases I am familiar with, the only time the authorization server may decide not to issue a new refresh token is when it is sure the current refresh token is not going to be expired sooner than the next refresh token request - AKA NEVER.
2. It is a good idea that the authorization server revoke the old refresh token, but it may be better to think about the chance of network failure as well. Let say a client has a token granted via password, and now, it has to request for a refresh token. The request will be accepted by the server, but the response is not reached backed to the client. Now the client should ask for the user's password, only because of a temporary network error.

So I propose that the server should revoke the old refresh token only after it is sure the client has the new one. To make sure about it the server may do as followed:

1. Revoke the old refresh token the first time the new access/refresh token is used.
2. Revoke the new refresh token, if the old but un-revoked refresh token is used again, which indicates that the new refresh token is never delivered to the client.

The OAuth2 spec (https://tools.ietf.org/html/rfc6749#section-6) states:

scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.  The requested scope MUST NOT include any scope
         not originally granted by the resource owner, and if omitted is
         treated as equal to the scope originally granted by the
         resource owner.

This library however interprets that to say: 'the scopes that were originally in the access token', but the spec only says: 'scopes granted by the resource owner'. Therefore, if I show the resource owner a prompt to approve for instance the test and demo scopes, and they are approved, but I remove demo in the finalizeScopes() call, because this scope is not available (right now) for the resource owner to grant, it will never be included after refreshing, even if it becomes available again lateron, while the user did grant permission.

Use case

In an API I'm building OAuth2 scopes are used for permissions. People can request data from an endpoint, but that endpoint may be temporarily disabled for some users during data updates, or at the end of the year, if the data gets updated for the next year.

Therefore, applications can request a scope for that endpoint, but they may temporarily not be granted the scope. I, however, don't want to force them to login again if the scope becomes available again, because the resource owner did grant permission after all. It should transparently be added back in, as the resource owner would expect. Scopes not allowed during the initial call, whether they were available or not, were never approved, and therefore should, as the spec says, never be included, even if their availability changes.

First of all, please do not touch my files... I do not think it's the responsibility of a package to set file permissions. It is the responsibility of your deployment pipeline or developers themselves.

While I appreciate the intent that was done in 2f8de3d2302beb490abb9475cf426148801c25c4. This is breaking for us in both our development and our production environments. And according to #760 for more people.

With this PR I would like to propose two things:

• First and foremost, remove any code that modifies files. However, do trigger a USER_NOTICE when not set to 600.
• Option to skip the check. This can be useful for DEV environments.

A bit of context for our case:

Our PROD setup is as follows: We have 4 users: deploy, worker, scheduler and apache. All four are part of the deployment group. So our code is chowned as deploy:deployment. So while 600 might seems like a good assumption, it will prevent our apache user from reading the key, thus breaking the web requests.

Our DEV setup is a bit different: We have our own users, yannickl88 in my case, and www-data for the web user. Files are chmodded 666 so both users can read everything. (we have a umask 0000 everywhere). While not the best setup, it's just development. In this case 660 is even not enough, but a warning would be justified. However, we would like to silence this in our DEV environment since Symfony converts the USER_NOTICE to an exception, making the lib unusable.

the implementation is wrong if ($keyPathPerms !== '600') {

you cant say that this is the perfect permission. you might have set up the file with permission to the group

which you then have '660'

AFAIK when using only the client credentials grant, one can use a client without any redirect URI (as it's not used anywhere in this grant).

Change introduced in #1140 makes it impossible to use such client.

Hello! I'm trying to implement Zapier as a client for a php slim app. Everything seems to be working great (even authorization, returning the correct data on custom endpoints) but the token expires after an hour and after that, zapier requires me to re-authorize the app, including opening the scopes window. By following the documentation, it seems that both routes (request access token and refresh) seem to be the same, so I've pointed both settings to the same route. Am I missing something here? Thank you for your help!

Updates the requirements on phpunit/phpunit to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Token exchange is a new grant type defined by the IETF providing support for impersonation and delegation scenarios, such as the following:

Illustration by Scott Brady

In a nutshell, the grant type involves the following steps:

Exchanging a token

This uses a new grant type of urn:ietf:params:oauth:grant-type:token-exchange and allows the requester to identify and authenticate themselves. Here, API1 is swapping the token it received for access to API2.

The subject token is the token sent by the client application, delegated by the user. Since this token was delegated using OAuth, the subject token type is urn:ietf:params:oauth:token-type:access_token (an access token).

POST /token
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&client_id=api1
&client_secret=secret
&scope=api2
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subject_token_type=urn:ietf:params:oauth:token-type:access_token

Token exchange response

The token response for token exchange is then slightly different than what you are used to:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
  "access_token": "lt6QCYJ58k44GRoCwwBPcFDPzYzHdGClhM9qCuh39DIL",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 60
}

The issued_token_type tells API1 (now acting as a client application) that it has sent back an access token. This allows API1 to understand how to use the token it has just received. In this case, it’s an access token that it can use to access a protected resource (API2).

The access token

The initial token was delegated by user, to the client application app, and you’re still acting on their behalf. But, by using the act claim set, you can show that api1 is the current actor. At the very least, this would be valuable for audit trials.

{
  "iss": "https://auth.example.com",
  "sub": "123xyz_user",
  "client_id": "app",
  "aud": "api2",
  "scope": "api2",
  "act": {
    "client_id": "api1"
  },
  "exp": 1443904177,
  "nbf": 1443904077
}

In addition to the act claim type, the Authorized Actor claim type (may_act) allows you to explicitly state who is allowed to act on someone’s behalf. For instance, if you wanted to explicitly state that api1 is authorized to act on app’s behalf, then the original access token API1 receives, may look like:

{
  "iss": "https://auth.example.com",
  "sub": "123xyz_user",
  "client_id": "app",
  "aud": "api1",
  "scope": "api1",
  "may_act": {
    "client_id": "api1"
  },
  "exp": 1443904177,
  "nbf": 1443904077
}

Now, when validating a token exchange request, the authorization server can check that the subject token has this may_act and that it includes the ID of the token exchange requester.

Use Cases

Token Exchange is great for API-to-API delegation, stuff like customer service acting on behalf of a customer, and preserving clear audit trails across services, as well as checking that zero trust checkbox on your compliance terms thoroughly.

I would love to see token exchange being implemented in oauth2-server, and subsequently in Laravel Passport. I have quite a bit of experience working with OAuth in PHP and would like to contribute to this, if there's any interest in implementing that grant type.

Updates the requirements on league/event to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR upgrades League\Event to version 3 while making the upgrade process smooth. I've added compatibility layers in to make the upgrade process smooth for users. Still, because return types are different, these changes are technically BC breaks.