« DeepSeek apiplatform keycloak » : différence entre les versions

Ligne 191 : Ligne 191 :
:Il est généralement inclus dans l'en-tête `Authorization` des requêtes HTTP sous la forme :
:Il est généralement inclus dans l'en-tête `Authorization` des requêtes HTTP sous la forme :
:<code>Authorization: Bearer <Access_Token></code>
:<code>Authorization: Bearer <Access_Token></code>
===='''Contenu''' :====
- Il contient des informations sur les '''permissions''' (scopes) et les '''rôles''' de l'utilisateur.
- Exemple de payload d'un Access Token (JWT) :
  ```json
  {
    "sub": "1234567890", // Identifiant de l'utilisateur
    "name": "John Doe",
    "roles": ["ROLE_USER", "ROLE_ADMIN"],
    "scope": "read write",
    "exp": 1672444800, // Date d'expiration
    "iat": 1672441200  // Date d'émission
  }
  ```
===='''Utilisation avec API Platform''' :====
- API Platform utilise l''''Access Token''' pour :
  1. Authentifier l'utilisateur (vérifier que le token est valide et signé par Keycloak).
  2. Autoriser l'accès aux routes ou opérations en fonction des rôles ou permissions contenus dans le token.
---
===2. '''ID Token'''===
===='''Rôle''' :====
- L''''ID Token''' est utilisé pour authentifier l'utilisateur auprès du client (application frontale ou mobile).
- Il est généralement utilisé dans des flux '''OpenID Connect''' (OIDC) pour fournir des informations sur l'utilisateur.
===='''Contenu''' :====
- Il contient des informations sur l'utilisateur (comme son identifiant, son nom, son email, etc.).
- Exemple de payload d'un ID Token (JWT) :
  ```json
  {
    "sub": "1234567890", // Identifiant de l'utilisateur
    "name": "John Doe",
    "email": "john.doe@example.com",
    "email_verified": true,
    "exp": 1672444800, // Date d'expiration
    "iat": 1672441200  // Date d'émission
  }
  ```
===='''Utilisation avec API Platform''' :====
- L''''ID Token''' n'est '''pas utilisé directement par API Platform'''.
- Il est principalement utilisé par le client (frontend) pour :
  1. Connaître les informations de l'utilisateur (nom, email, etc.).
  2. Maintenir une session utilisateur côté client.
---
===3. '''Différences clés entre ID Token et Access Token'''===
| '''Aspect'''              | '''ID Token'''                          | '''Access Token'''                      |
|--------------------------|---------------------------------------|---------------------------------------|
| '''But'''                | Authentifier l'utilisateur côté client. | Accéder aux ressources protégées (API). |
| '''Public cible'''        | Client (frontend ou application mobile). | Serveur (API Platform).              |
| '''Contenu'''            | Informations sur l'utilisateur (nom, email, etc.). | Rôles, permissions, et scopes.        |
| '''Protocole'''          | OpenID Connect (OIDC).                | OAuth2.                              |
| '''Utilisation dans API Platform''' | Non utilisé directement.            | Utilisé pour l'authentification et l'autorisation. |
---
===4. '''Flux typique avec API Platform et Keycloak'''===
====1. '''Authentification''' :====
  - L'utilisateur se connecte via Keycloak (flux OAuth2/OpenID Connect).
  - Keycloak renvoie un '''ID Token''' et un '''Access Token''' au client.
====2. '''Utilisation côté client''' :====
  - Le client utilise l''''ID Token''' pour afficher les informations de l'utilisateur (nom, email, etc.).
  - Le client utilise l''''Access Token''' pour accéder aux API protégées.
====3. '''Accès aux API''' :====
  - Le client envoie l''''Access Token''' dans l'en-tête `Authorization` des requêtes API.
  - API Platform valide l''''Access Token''' et vérifie les permissions avant de renvoyer les données.
---
===5. '''Exemple concret'''===
===='''Scénario''' :====
- Une application web utilise Keycloak pour l'authentification et API Platform pour exposer des API.
===='''Étapes''' :====
=====1. '''Connexion''' :=====
  - L'utilisateur se connecte via Keycloak.
  - Keycloak renvoie :
    ```json
    {
      "id_token": "<ID_Token>",
      "access_token": "<Access_Token>",
      "refresh_token": "<Refresh_Token>"
    }
    ```
=====2. '''Utilisation côté client''' :=====
  - Le client décode l''''ID Token''' pour afficher le nom et l'email de l'utilisateur.
  - Le client envoie l''''Access Token''' dans les requêtes API :
    ```http
    GET /api/products
    Authorization: Bearer <Access_Token>
    ```
=====3. '''Validation côté serveur''' :=====
  - API Platform valide l''''Access Token''' en utilisant la clé publique de Keycloak.
  - Si le token est valide et que l'utilisateur a les permissions nécessaires, l'API renvoie les données.
---
===6. '''Bonnes pratiques'''===
- '''Ne jamais exposer l'Access Token côté client''' : Il doit être utilisé uniquement pour accéder aux API.
- '''Utiliser HTTPS''' : Pour protéger les tokens lors de leur transmission.
- '''Vérifier les scopes et rôles''' : Assurez-vous que l'Access Token contient les permissions nécessaires pour accéder aux ressources.
---
En résumé, l''''ID Token''' est utilisé pour authentifier l'utilisateur côté client, tandis que l''''Access Token''' est utilisé pour accéder aux ressources protégées côté serveur (API Platform). Les deux sont essentiels dans une architecture sécurisée utilisant Keycloak et API Platform.


[[category:DeepSeek]] [[category:api]]
[[category:DeepSeek]] [[category:api]]