Aller au contenu

Apiplatform keycloak debug

De Marmits Wiki

La structure et le contenu de l’accessToken peuvent absolument être une raison pour laquelle la méthode getUserBadgeFrom n’est pas appelée. Si l’accessToken ne respecte pas les exigences de votre configuration (comme les claims obligatoires, la signature, ou l’algorithme), le processus d’authentification peut échouer avant même que la méthode getUserBadgeFrom ne soit atteinte.

Voici une analyse détaillée des raisons possibles liées à l’accessToken pour lesquelles getUserBadgeFrom n’est pas appelée, ainsi que des solutions pour résoudre ces problèmes :



1. L’accessToken est invalide ou malformé

Problème

Si l’accessToken n’est pas un token JWT valide (par exemple, il est malformé ou ne respecte pas la structure JWT), la validation échouera avant que getUserBadgeFrom ne soit appelée.

Solution

  • Vérifiez que l’accessToken est un token JWT valide.

  • Assurez-vous qu’il est bien structuré en trois parties (header, payload, signature) séparées par des points (.).

  • Exemple de token JWT valide :

    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c



2. Les claims obligatoires sont manquants

Problème

Si l’accessToken ne contient pas les claims obligatoires (iat, nbf, exp, aud, iss), la validation échouera.

Solution

  • Vérifiez que l’accessToken contient tous les claims requis :

    • iat : Date de création du token.
    • nbf : Date avant laquelle le token n’est pas valide.
    • exp : Date d’expiration du token.
    • aud : Le destinataire du token (doit correspondre à %env(OIDC_AUD)%).
    • iss : L’émetteur du token (doit correspondre à %env(OIDC_SERVER_URL)%).
  • Exemple de payload valide :

    {
      "sub": "1234567890",
      "email": "john.doe@example.com",
      "iat": 1516239022,
      "nbf": 1516239022,
      "exp": 1516239122,
      "aud": "your-client-id",
      "iss": "https://your-keycloak-domain/auth/realms/your-realm"
    }
    



3. La signature est invalide

Problème

Si la signature du token JWT est invalide (par exemple, elle ne correspond pas à l’algorithme spécifié dans le header ou les clés publiques de Keycloak), la validation échouera.

Solution

  • Vérifiez que la signature du token est valide.

  • Assurez-vous que l’algorithme de signature (alg) dans le header correspond à l’un des algorithmes configurés (HS256, RS256, ou ES256).

  • Exemple de header valide :

    {
      "alg": "RS256",
      "typ": "JWT"
    }
    
  • Assurez-vous que les clés publiques de Keycloak sont correctement configurées pour valider la signature.



4. L’algorithme de signature n’est pas supporté

Problème

Si l’algorithme de signature (alg) dans le header du token JWT n’est pas l’un des algorithmes configurés (HS256, RS256, ou ES256), la validation échouera.

Solution

  • Vérifiez que l’algorithme de signature dans le header est l’un des suivants : HS256, RS256, ou ES256.

  • Exemple de header valide :

    {
      "alg": "RS256",
      "typ": "JWT"
    }
    



5. Le token est expiré

Problème

Si le token JWT est expiré (la date actuelle est postérieure à la valeur du claim exp), la validation échouera.

Solution

  • Vérifiez que le token n’est pas expiré.

  • Assurez-vous que la valeur du claim exp est dans le futur.

  • Exemple de claim exp valide :

    {
      "exp": 1516239122
    }
    



6. Le token n’est pas encore valide

Problème

Si le token JWT n’est pas encore valide (la date actuelle est antérieure à la valeur du claim nbf), la validation échouera.

Solution

  • Vérifiez que le token est valide en comparant la date actuelle avec la valeur du claim nbf.

  • Exemple de claim nbf valide :

    {
      "nbf": 1516239022
    }
    



7. L’audience ou l’émetteur est incorrect

Problème

Si les claims aud (audience) ou iss (issuer) ne correspondent pas aux valeurs configurées (%env(OIDC_AUD)% et %env(OIDC_SERVER_URL)%), la validation échouera.

Solution

  • Vérifiez que les claims aud et iss dans le token JWT correspondent aux valeurs attendues.

  • Exemple de claims valides :

    {
      "aud": "your-client-id",
      "iss": "https://your-keycloak-domain/auth/realms/your-realm"
    }
    



8. Comment diagnostiquer le problème

Pour diagnostiquer pourquoi getUserBadgeFrom n’est pas appelée, suivez ces étapes :

a. Activer les logs de sécurité

Activez les logs de sécurité pour voir les erreurs de validation du token. Ajoutez ceci à votre fichier config/packages/dev/monolog.yaml :

monolog:
    handlers:
        security:
            type: stream
            path: '%kernel.logs_dir%/security.log'
            level: debug
            channels: ['security']

Ensuite, vérifiez le fichier var/log/security.log pour des messages d’erreur.

b. Tester manuellement la validation du token

Créez un contrôleur temporaire pour tester la validation du token :

namespace App\Controller;

use App\Security\Http\AccessToken\Oidc\OidcDiscoveryTokenHandler;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class TestController
{
    #[Route('/test-token', name: 'test_token')]
    public function testToken(OidcDiscoveryTokenHandler $tokenHandler): JsonResponse
    {
        $token = 'votre-token-jwt';
        try {
            $userBadge = $tokenHandler->getUserBadgeFrom($token);
            return new JsonResponse(['success' => true, 'user' => $userBadge->getUserIdentifier()]);
        } catch (\Throwable $e) {
            return new JsonResponse(['error' => $e->getMessage()], 400);
        }
    }
}

Envoyez une requête à /test-token avec votre token JWT pour voir si la validation fonctionne.



9. Résumé

La méthode getUserBadgeFrom n’est pas appelée si : - L’accessToken est invalide ou malformé. - Les claims obligatoires (iat, nbf, exp, aud, iss) sont manquants ou incorrects. - La signature est invalide ou l’algorithme de signature n’est pas supporté. - Le token est expiré ou pas encore valide.

Pour résoudre le problème : 1. Vérifiez que l’accessToken est un token JWT valide. 2. Assurez-vous que les claims obligatoires sont présents et corrects. 3. Activez les logs de sécurité pour diagnostiquer les erreurs. 4. Testez manuellement la validation du token.


10. source du paramétrage

web-token/jwt-bundle

jose:
    jws:
        serializers:
            oidc:
                serializers: ['jws_compact']
                is_public: true
        loaders:
            oidc:
                serializers: ['jws_compact']
                signature_algorithms: ['HS256', 'RS256', 'ES256']
                header_checkers: ['alg', 'iat', 'nbf', 'exp', 'aud', 'iss']
                is_public: true
    checkers:
        claims:
            oidc:
                is_public: true
                claims: ['iat', 'nbf', 'exp']
        headers:
            oidc:
                is_public: true
                headers: ['alg', 'iss', 'aud']

services:
    _defaults:
        autowire: true
        autoconfigure: true

    Jose\Component\Checker\AlgorithmChecker:
        arguments:
            $supportedAlgorithms: ['HS256', 'RS256', 'ES256']
        tags:
            - name: 'jose.checker.header'
              alias: 'alg'
    Jose\Component\Checker\AudienceChecker:
        arguments:
            $audience: '%env(OIDC_AUD)%'
        tags:
            - name: 'jose.checker.header'
              alias: 'aud'
    Jose\Component\Checker\IssuerChecker:
        arguments:
            $issuers: ['%env(OIDC_SERVER_URL)%']
        tags:
            - name: 'jose.checker.header'
              alias: 'iss'

when@test:
    jose:
        jws:
            builders:
                oidc:
                    signature_algorithms: ['HS256', 'RS256', 'ES256']
                    is_public: true

source:DeepSeek