添加链接 注册    登录
link管理
链接快照平台
  • 输入网页链接，自动生成快照
  • 标签化管理网页链接
相关文章推荐
英俊的大葱  ·  webpack + Travis CI ...·  2 天前    · 
深情的针织衫  ·  在4个街道划定高风险区！深圳2区发布最新通告 ...·  4 月前    · 
小胡子的领带  ·  datacamp-python-data-s ...·  5 月前    · 
温柔的西瓜  ·  Python清空Excel内容但不删除表头 ...·  5 月前    · 
谦和的数据线  ·  React ...·  6 月前    · 
愤怒的警车  ·  Recovery of flash ...·  6 月前    · 
link管理  ›  How to use Access Token Authentication (Symfony Docs)
symfony handler access token
https://symfony.com/doc/current/security/access_token.html
一身肌肉的松球
6 月前

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.). 

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token token-handler="App\Security\AccessTokenHandler"/>
        </firewall>
    </config>
</srv:container>
// config/packages/security.php
use App\Security\AccessTokenHandler;
use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security): void {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler(AccessTokenHandler::class)
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.

                Caution
    
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.
                Caution
    
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.

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token token-handler="App\Security\AccessTokenHandler">
                <!-- use a different built-in extractor -->
                <token-extractor>request_body</token-extractor>
                <!-- or provide the service ID of a custom extractor -->
                <token-extractor>App\Security\CustomTokenExtractor</token-extractor>
            </access-token>
        </firewall>
    </config>
</srv:container>

        
// config/packages/security.php
use App\Security\AccessTokenHandler;
use App\Security\CustomTokenExtractor;
use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security): void {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler(AccessTokenHandler::class)
            // use a different built-in extractor
            ->tokenExtractors('request_body')
            # or provide the service ID of a custom extractor
            ->tokenExtractors(CustomTokenExtractor::class)
        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token token-handler="App\Security\AccessTokenHandler">
                <token-extractor>header</token-extractor>
                <token-extractor>App\Security\CustomTokenExtractor</token-extractor>
            </access-token>
        </firewall>
    </config>
</srv:container>

        
// config/packages/security.php
use App\Security\AccessTokenHandler;
use App\Security\CustomTokenExtractor;
use Symfony




    
\Config\SecurityConfig;
return static function (SecurityConfig $security): void {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler(AccessTokenHandler::class)
            ->tokenExtractors([
                'header',
                CustomTokenExtractor::class,

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:

        
$ 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:

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token token-handler="App\Security\AccessTokenHandler"
                success-handler="App\Security\Authentication\AuthenticationSuccessHandler"
        </firewall>
    </config>
</srv:container>

        
// config/packages/security.php
use App\Security\AccessTokenHandler;
use App\Security\Authentication\AuthenticationSuccessHandler;
use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security): void {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler(AccessTokenHandler::class)
            ->successHandler(AuthenticationSuccessHandler::class)
    
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:

        
$ composer require symfony/http-client


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

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler oidc-user-info="https://www.example.com/realms/demo/protocol/openid-connect/userinfo"/>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->oidcUserInfo('https://www.example.com/realms/demo/protocol/openid-connect/userinfo')
        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <oidc-user-info claim="email" base-uri="https://www.example.com/realms/demo/protocol/openid-connect/userinfo"/>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->oidcUserInfo()
                    ->claim('email')
                    ->baseUri('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:

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <oidc-user-info client="oidc.client"/>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->oidcUserInfo()
                    ->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:

        
// 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:

        
$ composer require web-token/jwt-library


Symfony provides a generic OidcTokenHandler to decode your token, validate
it and retrieve the user info from it:

                        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']

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <!-- Algorithm used to sign the JWS -->
                    <!-- A JSON-encoded JWK -->
                    <!-- Audience (`aud` claim): required for validation purpose -->
                    <oidc keyset="{'keys':[{'kty':'...','k':'...'}]}" audience="api-example">
                        <!-- Issuers (`iss` claim): required for validation purpose -->
                        <algorithm>ES256</algorithm>
                        <algorithm>RS256</algorithm>
                        <issuer>https://oidc.example.com</issuer>
                    </oidc>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->oidc()
                    // Algorithm 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'])
    
The support of multiple algorithms to sign the JWS was introduced in Symfony 7.1.
In previous versions, only the ES256 algorithm was supported.


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

                        claim: email
                        algorithms: ['ES256', 'RS256']
                        keyset: '{"keys":[{"kty":"...","k":"..."}]}'
                        audience: 'api-example'
                        issuers: ['https://oidc.example.com']

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <oidc claim="email" keyset="{'keys':[{'kty':'...','k':'...'}]}" audience="api-example">
                        <algorithm>ES256</algorithm>
                        <algorithm>RS256</algorithm>
                        <issuer>https://oidc.example.com</issuer>
                    </oidc>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->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:

        
// 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
    
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:

        
$ composer require symfony/http-client


You can configure a cas token handler as follows:

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <cas validation-url="https://www.example.com/cas/validate"/>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->cas()
                    ->validationUrl('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:

        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <cas validation-url="https://www.example.com/cas/validate" http-client="cas.client"/>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->cas()
                    ->validationUrl('https://www.example.com/cas/validate')
                    ->httpClient('cas.client')
        
<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">
    <config>
        <firewall name="main">
            <access-token>
                <token-handler>
                    <cas validation-url="https://www.example.com/cas/validate" prefix="cas-example"/>
                </token-handler>
            </access-token>
        </firewall>
    </config>
</srv:container>

use Symfony\Config\SecurityConfig;
return static function (SecurityConfig $security) {
    $security->firewall('main')
        ->accessToken()
            ->tokenHandler()
                ->cas()
                    ->validationUrl('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:

        
// 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.

                                    Be an active part of the community and contribute ideas, code and bug fixes.
                                    Both experts and newcomers are welcome.
                                Learn how to contribute
 
推荐文章
英俊的大葱  ·  webpack + Travis CI 自动部署项目应用 | Anran758's blog
2 天前
深情的针织衫  ·  在4个街道划定高风险区！深圳2区发布最新通告_深圳24小时_深新闻_奥一网
4 月前
小胡子的领带  ·  datacamp-python-data-science/pandas_square_brackets.py at master · cleefsouza/datacamp-python-data-s
5 月前
温柔的西瓜  ·  Python清空Excel内容但不删除表头 - CSDN文库
5 月前
谦和的数据线  ·  React redux不更新数据_React Native FlatList在数据更新时不呈现(Redux)_React Redux不更新文本输入onChange - 腾讯云开发者社区 - 腾讯云
6 月前
愤怒的警车  ·  Recovery of flash corrupted ePMP Force 300-13L/Force 300-25L caused due to power interruption during
6 月前
Link管理   ·   51好读   ·   Sov5搜索   ·   小百科
link管理 - 链接快照平台