How to use Access Token Authentication

Edit this page

Access tokens or API tokens are commonly used as authentication mechanism in API contexts. The access token is a string, obtained during authentication (using the application or an authorization server). The access token's role is to verify the user identity and receive consent before the token is issued.

Access tokens can be of any kind, for instance opaque strings, JSON Web Tokens (JWT) or SAML2 (XML structures). Please refer to the RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage for a detailed specification.

Using the Access Token Authenticator

This guide assumes you have setup security and have created a user object in your application. Follow the main security guide if this is not yet the case.

1) Configure the Access Token Authenticator

To use the access token authenticator, you must configure a token_handler. The token handler receives the token from the request and returns the correct user identifier. To get the user identifier, implementations may need to load and validate the token (e.g. revocation, expiration time, digital signature, etc.).

1
2
3
4
5
6
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler: App\Security\AccessTokenHandler

This handler must implement AccessTokenHandlerInterface:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// src/Security/AccessTokenHandler.php
namespace App\Security;

use App\Repository\AccessTokenRepository;
use Symfony\Component\Security\Core\Exception\BadCredentialsException;
use Symfony\Component\Security\Http\AccessToken\AccessTokenHandlerInterface;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;

class AccessTokenHandler implements AccessTokenHandlerInterface
{
    public function __construct(
        private AccessTokenRepository $repository
    ) {
    }

    public function getUserBadgeFrom(string $accessToken): UserBadge
    {
        // e.g. query the "access token" database to search for this token
        $accessToken = $this->repository->findOneByValue($accessToken);
        if (null === $accessToken || !$accessToken->isValid()) {
            throw new BadCredentialsException('Invalid credentials.');
        }

        // and return a UserBadge object containing the user identifier from the found token
        // (this is the same identifier used in Security configuration; it can be an email,
        // a UUID, a username, a database ID, etc.)
        return new UserBadge($accessToken->getUserId());
    }
}

The access token authenticator will use the returned user identifier to load the user using the user provider.

Warning

It is important to check the token if is valid. For instance, the example above verifies whether the token has not expired. With self-contained access tokens such as JWT, the handler is required to verify the digital signature and understand all claims, especially sub, iat, nbf and exp.

2) Configure the Token Extractor (Optional)

The application is now ready to handle incoming tokens. A token extractor retrieves the token from the request (e.g. a header or request body).

By default, the access token is read from the request header parameter Authorization with the scheme Bearer (e.g. Authorization: Bearer the-token-value).

Symfony provides other extractors as per the RFC6750:

header (default)
The token is sent through the request header. Usually Authorization with the Bearer scheme.
query_string
The token is part of the request query string. Usually access_token.
request_body
The token is part of the request body during a POST request. Usually access_token.

Warning

Because of the security weaknesses associated with the URI method, including the high likelihood that the URL or the request body containing the access token will be logged, methods query_string and request_body SHOULD NOT be used unless it is impossible to transport the access token in the request header field.

You can also create a custom extractor. The class must implement AccessTokenExtractorInterface.

1
2
3
4
5
6
7
8
9
10
11
12
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler: App\Security\AccessTokenHandler

                # use a different built-in extractor
                token_extractors: request_body

                # or provide the service ID of a custom extractor
                token_extractors: 'App\Security\CustomTokenExtractor'

It is possible to set multiple extractors. In this case, the order is important: the first in the list is called first.

1
2
3
4
5
6
7
8
9
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler: App\Security\AccessTokenHandler
                token_extractors:
                    - 'header'
                    - 'App\Security\CustomTokenExtractor'

3) Submit a Request

That's it! Your application can now authenticate incoming requests using an API token.

Using the default header extractor, you can test the feature by submitting a request like this:

1
2
$ curl -H 'Authorization: Bearer an-accepted-token-value' \
    https://localhost:8000/api/some-route

Customizing the Success Handler

By default, the request continues (e.g. the controller for the route is run). If you want to customize success handling, create your own success handler by creating a class that implements AuthenticationSuccessHandlerInterface and configure the service ID as the success_handler:

1
2
3
4
5
6
7
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler: App\Security\AccessTokenHandler
                success_handler: App\Security\Authentication\AuthenticationSuccessHandler

Tip

If you want to customize the default failure handling, use the failure_handler option and create a class that implements AuthenticationFailureHandlerInterface.

Using OpenID Connect (OIDC)

OpenID Connect (OIDC) is the third generation of OpenID technology and it's a RESTful HTTP API that uses JSON as its data format. OpenID Connect is an authentication layer on top of the OAuth 2.0 authorization framework. It allows to verify the identity of an end user based on the authentication performed by an authorization server.

1) Configure the OidcUserInfoTokenHandler

The OidcUserInfoTokenHandler requires the symfony/http-client package to make the needed HTTP requests. If you haven't installed it yet, run this command:

1
$ composer require symfony/http-client

Symfony provides a generic OidcUserInfoTokenHandler to call your OIDC server and retrieve the user info:

1
2
3
4
5
6
7
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc_user_info: https://www.example.com/realms/demo/protocol/openid-connect/userinfo

To enable OpenID Connect Discovery, the OidcUserInfoTokenHandler requires the symfony/cache package to store the OIDC configuration in the cache. If you haven't installed it yet, run the following command:

1
$ composer require symfony/cache

Next, configure the base_uri and discovery options:

1
2
3
4
5
6
7
8
9
10
11
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc_user_info:
                        base_uri: https://www.example.com/realms/demo/
                        discovery:
                            cache:
                                id: cache.app

7.3

Support for OpenID Connect Discovery was introduced in Symfony 7.3.

Following the OpenID Connect Specification, the sub claim is used as user identifier by default. To use another claim, specify it using the claim option:

1
2
3
4
5
6
7
8
9
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc_user_info:
                        claim: email
                        base_uri: https://www.example.com/realms/demo/protocol/openid-connect/userinfo

The oidc_user_info token handler automatically creates an HTTP client with the specified base_uri. If you prefer using your own client, you can specify the service name via the client option:

1
2
3
4
5
6
7
8
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc_user_info:
                        client: oidc.client

By default, the OidcUserInfoTokenHandler creates an OidcUser with the claims. To create your own user object from the claims, you must create your own UserProvider:

1
2
3
4
5
6
7
8
9
10
// src/Security/Core/User/OidcUserProvider.php
use Symfony\Component\Security\Core\User\AttributesBasedUserProviderInterface;

class OidcUserProvider implements AttributesBasedUserProviderInterface
{
    public function loadUserByIdentifier(string $identifier, array $attributes = []): UserInterface
    {
        // implement your own logic to load and return the user object
    }
}

2) Configure the OidcTokenHandler

The OidcTokenHandler requires the web-token/jwt-library package. If you haven't installed it yet, run this command:

1
$ composer require web-token/jwt-library

Symfony provides a generic OidcTokenHandler that decodes the token, validates it, and retrieves the user information from it. Optionally, the token can be encrypted (JWE):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc:
                        # Algorithms used to sign the JWS
                        algorithms: ['ES256', 'RS256']
                        # A JSON-encoded JWK
                        keyset: '{"keys":[{"kty":"...","k":"..."}]}'
                        # Audience (`aud` claim): required for validation purpose
                        audience: 'api-example'
                        # Issuers (`iss` claim): required for validation purpose
                        issuers: ['https://oidc.example.com']
                        encryption:
                            enabled: true # Default to false
                            enforce: false # Default to false, requires an encrypted token when true
                            algorithms: ['ECDH-ES', 'A128GCM']
                            keyset: '{"keys": [...]}' # Encryption private keyset

7.1

The support of multiple algorithms to sign the JWS was introduced in Symfony 7.1. In previous versions, only the ES256 algorithm was supported.

7.3

Support for encryption algorithms to decrypt JWEs was introduced in Symfony 7.3.

To enable OpenID Connect Discovery, the OidcTokenHandler requires the symfony/cache package to store the OIDC configuration in the cache. If you haven't installed it yet, run the following command:

1
$ composer require symfony/cache

Then, you can remove the keyset configuration option (it will be imported from the OpenID Connect Discovery), and configure the discovery option:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc:
                        claim: email
                        algorithms: ['ES256', 'RS256']
                        audience: 'api-example'
                        issuers: ['https://oidc.example.com']
                        discovery:
                            base_uri: https://www.example.com/realms/demo/
                            cache:
                                id: cache.app

Following the OpenID Connect Specification, the sub claim is used by default as user identifier. To use another claim, specify it on the configuration:

1
2
3
4
5
6
7
8
9
10
11
12
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc:
                        claim: email
                        algorithms: ['ES256', 'RS256']
                        keyset: '{"keys":[{"kty":"...","k":"..."}]}'
                        audience: 'api-example'
                        issuers: ['https://oidc.example.com']

By default, the OidcTokenHandler creates an OidcUser with the claims. To create your own User from the claims, you must create your own UserProvider:

1
2
3
4
5
6
7
8
9
10
// src/Security/Core/User/OidcUserProvider.php
use Symfony\Component\Security\Core\User\AttributesBasedUserProviderInterface;

class OidcUserProvider implements AttributesBasedUserProviderInterface
{
    public function loadUserByIdentifier(string $identifier, array $attributes = []): UserInterface
    {
        // implement your own logic to load and return the user object
    }
}

Configuring Multiple OIDC Discovery Endpoints

7.4

Support for multiple OIDC discovery endpoints was introduced in Symfony 7.4.

The OidcTokenHandler supports multiple OIDC discovery endpoints, allowing it to validate tokens from different identity providers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    oidc:
                        algorithms: ['ES256', 'RS256']
                        audience: 'api-example'
                        issuers: ['https://oidc1.example.com', 'https://oidc2.example.com']
                        discovery:
                            base_uri:
                                - https://idp1.example.com/realms/demo/
                                - https://idp2.example.com/realms/demo/
                            cache:
                                id: cache.app

The token handler fetches the JWK sets from all configured discovery endpoints and builds a combined JWK set for token validation. This lets your application accept and validate tokens from multiple identity providers within a single firewall.

Creating a OIDC token from the command line

7.4

The security:oidc:generate-token command was introduced in Symfony 7.4.

The security:oidc:generate-token command helps you generate JWTs. It's mostly useful when developing or testing applications that use OIDC authentication:

1
2
3
4
5
6
7
8
# generate a token using the default configuration
$ php bin/console security:oidc:generate-token john.doe@example.com

# specify the firewall, algorithm, and issuer if multiple are available
$ php bin/console security:oidc:generate-token john.doe@example.com \
    --firewall="api" \
    --algorithm="HS256" \
    --issuer="https://example.com"

Note

The JWK used for signing must have the appropriate key operation flags set.

Using CAS 2.0

7.1

The support for CAS token handlers was introduced in Symfony 7.1.

Central Authentication Service (CAS) is an enterprise multilingual single sign-on solution and identity provider for the web and attempts to be a comprehensive platform for your authentication and authorization needs.

Configure the Cas2Handler

Symfony provides a generic Cas2Handler to call your CAS server. It requires the symfony/http-client package to make the needed HTTP requests. If you haven't installed it yet, run this command:

1
$ composer require symfony/http-client

You can configure a cas token handler as follows:

1
2
3
4
5
6
7
8
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    cas:
                        validation_url: https://www.example.com/cas/validate

The cas token handler automatically creates an HTTP client to call the specified validation_url. If you prefer using your own client, you can specify the service name via the http_client option:

1
2
3
4
5
6
7
8
9
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    cas:
                        validation_url: https://www.example.com/cas/validate
                        http_client: cas.client
By default the token handler will read the validation URL XML response with
cas prefix but you can configure another prefix: 
1
2
3
4
5
6
7
8
9
# config/packages/security.yaml
security:
    firewalls:
        main:
            access_token:
                token_handler:
                    cas:
                        validation_url: https://www.example.com/cas/validate
                        prefix: cas-example

Creating Users from Token

Some types of tokens (for instance OIDC) contain all information required to create a user entity (e.g. username and roles). In this case, you don't need a user provider to create a user from the database:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// src/Security/AccessTokenHandler.php
namespace App\Security;

// ...
class AccessTokenHandler implements AccessTokenHandlerInterface
{
    // ...

    public function getUserBadgeFrom(string $accessToken): UserBadge
    {
        // get the data from the token
        $payload = ...;

        return new UserBadge(
            $payload->getUserId(),
            fn (string $userIdentifier) => new User($userIdentifier, $payload->getRoles())
        );
    }
}

When using this strategy, you can omit the user_provider configuration for stateless firewalls.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version