Add support for token revocation

[alexbilbie]

Add support for token revocation - http://tools.ietf.org/html/draft-ietf-oauth-revocation-06

Requires new method that will accept the following parameters by POST and will then use them to revoke an access token or refresh token:

• token (REQUIRED) The token that the client wants to get revoked
• token_type_hint (OPTIONAL) A hint about the type of the token submitted for revocation. Clients MAY pass this parameter in order to help the authorization server to optimize the token lookup. If the server is unable to locate the token using the given hint, it MUST extend its search accross all of its supported token types. An authorization server MAY ignore this parameter, particularly if it is able to detect the token type automatically. This specification defines two such values:
  • access_token
  • refresh_token
• client_id (OPTIONAL)
• client_secret (OPTIONAL)

If the client presents it's credentials it should be validated. If the client credentials are incorrect then respond with invalid_credentials error (from core spec).

If the server can't handle the presented token (if the token_type_hint parameter is used) then error with:

error=unsupported_token_type
&error_message=The authorization server does not support the  revocation of the presented token type.  I.e.  the client tried to revoke an access token on a server not supporting this feature.

The server should respond with 200 if the token revocation is successful or an invalid token is supplied.

[cziegenberg]

How do you define "If the server can't handle the presented token"?

For security reasons, the server should respond with status 200 if the token is invalid, so what does handle mean in this case? I would define it as "If the server can't handle the presented token type", e.g. if the server only revokes refresh tokens but not access tokens (as mentioned in point "2.1. Revocation Request").

So if the token type is not set, always return status 200. If the token type is set and generally supported (no matter if found or not), return status 200. Only if the token type is set and not supported, return an error (and status 400?).

Why is the client_id/client_secret optional?

If you don't check the client access, everyone could send token revoke requests and "launch denial of service attacks on the authorization server". In point "6. Security Considerations" it's mentioned as required: "According to this specification, a client's request must contain a valid client_id, in the case of a public client, or valid client credentials, in the case of a confidential client. The token being revoked must also belong to the requesting client."

So the client must always be authorized for the token revocation.

Also important for the implementation:

"If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on the same authorization grant. If the token passed to the request is an access token, the server MAY decide to revoke the respective refresh token as well."

[alexbilbie]

I've just paraphrased from the spec document

[bp1222]

I don't like the notion of the library supporting forced revocation, directly. Revoking to different people could mean different things

On one hand, revoke = purge access-token with a long expire date from the DB. Another, revoke = Flag access-token with long expire, to not be valid, but remain for historical purpose.

I'm being crazy, where access tokens aren't ever purged, but are retained to the session, which is retained to the client. In my implementation tokens are only valid once in a time of 10 seconds, but remain in the DB. Even after refresh. I can look to a client, and see history.

Point is, this is a user decision, and I'd like it kept that way.

[auro1]

@bp1222 I'm sure this would be implemented as optional.

[ganey]

If you verify the token you can then expire it with the AccessTokenEntity class.

\League\OAuth2\Server\ResourceServer->getAccessToken()->expire();

Expire does the following:

namespace League\OAuth2\Server\Entity;

class AccessTokenEntity extends AbstractTokenEntity
{
  ....

  public function expire()
  {
    $this->server->getAccessTokenStorage()->delete($this);
  }

Edit: I haven't checked to see if this affects any Refresh Tokens

[alexbilbie]

Closing this as now out of scope of project

[heisian]

i'm surprised there's not a more explicit revocation interface outlined for this.

i was attempting to use Laravel's softDeletes trait (deleted_at) column b/c I want to maintain a history of sessions and tokens, as opposed to deleting the record entirely...

what about sessions? I would like to be able to invalidate an entire session as well, cascading the results to their child tokens..

[heisian]

I think I'm onto something here... In the examples included with this repo you can set a custom Storage provider:

class CustomOAuth2ServerServiceProvider extends ServiceProvider
{

...

    public function registerAuthorizer()
    {
        $this->app->bindShared('oauth2-server.authorizer', function ($app) {
            $config = $app['config']->get('oauth2');
            $issuer = $app->make(AuthorizationServer::class)
                ->setClientStorage($app->make(ClientInterface::class))
                ->setSessionStorage(new \App\ExtensionsOAuth\SessionStorage())
                ->setAuthCodeStorage($app->make(AuthCodeInterface::class))
                ->setAccessTokenStorage($app->make(AccessTokenInterface::class))
                // ->setAccessTokenStorage(new \App\ExtensionsOAuth\SessionStorage())
                ->setRefreshTokenStorage($app->make(RefreshTokenInterface::class))
                ->setScopeStorage($app->make(ScopeInterface::class))
                ->requireScopeParam($config['scope_param'])
                ->setDefaultScope($config['default_scope'])
                ->requireStateParam($config['state_param'])
                ->setScopeDelimiter($config['scope_delimiter'])
                ->setAccessTokenTTL($config['access_token_ttl']);

...

And it seems like alls I need to do is add another condition to filter out deleted_at columns:

<?php

namespace ExtensionsOAuth;

use Illuminate\Database\Capsule\Manager as Capsule;
use League\OAuth2\Server\Entity\AccessTokenEntity;
use League\OAuth2\Server\Entity\AuthCodeEntity;
use League\OAuth2\Server\Entity\ScopeEntity;
use League\OAuth2\Server\Entity\SessionEntity;
use League\OAuth2\Server\Storage\AbstractStorage;
use League\OAuth2\Server\Storage\SessionInterface;

class SessionStorage extends AbstractStorage implements SessionInterface
{
    /**
     * {@inheritdoc}
     */
    public function getByAccessToken(AccessTokenEntity $accessToken)
    {
        $result = Capsule::table('oauth_sessions')
                            ->select(['oauth_sessions.id', 'oauth_sessions.owner_type', 'oauth_sessions.owner_id', 'oauth_sessions.client_id', 'oauth_sessions.client_redirect_uri'])
                            ->join('oauth_access_tokens', 'oauth_access_tokens.session_id', '=', 'oauth_sessions.id')
                            ->where('oauth_access_tokens.access_token', $accessToken->getId())
                            ->where('deleted_at', NULL)
                            ->get();

        if (count($result) === 1) {
            $session = new SessionEntity($this->server);
            $session->setId($result[0]['id']);
            $session->setOwner($result[0]['owner_type'], $result[0]['owner_id']);

            return $session;
        }

...

gonna give it a shot..