OpenID Connect

Protocol

OpenID Connect (OIDC) est une norme d'authentification ouverte basée sur le protocole 1.0 is a simple identity layer on top of the OAuth 2.0 . Elle permet à des clients, comme des applications ou des sites web, de vérifier l'identité d'un utilisateur et d'obtenir des informations de profil de base, tout en offrant un niveau élevé de sécurité et de facilité d'utilisation. OpenID Connect est une façon pratique et sûre de se connecter à plusieurs sites et applications sans avoir besoin de créer de nouveaux comptes à chaque fois.protocol. See the full documentation of the protocol here : https://openid.net/specs/openid-connect-core-1_0.html

Flot d’authentification : Authorization Code

La plateforme Édifice propose un serveur OAuth2 qui supporte les "flots" suivant :

• Authorization Code

• Resource Owner

• Password

• Client Credential

Le flot

Authorization Code ( Code d'Autorisation) d'OpenID Connect est un processus sécurisé utilisé pour authentifier un utilisateur et obtenir l'accès à ses informations. Il est particulièrement utilisé pour les applications serveur où la sécurité est primordiale.

• Demande d'Autorisation : L'utilisateur commence par tenter de se connecter à une application (le client ou Relying Party). L'application redirige ensuite l'utilisateur vers le serveur d'authentification où l'utilisateur se connecte et donne son consentement pour que l'application accède à ses informations.

• Redirection vers le Client : Après la connexion et le consentement, le serveur d'authentification redirige l'utilisateur vers l'application avec un "code d'autorisation" dans l'URL.

• Échange de Code contre un Token : L'application envoie ce code d'autorisation au serveur d'authentification, en arrière-plan, souvent en utilisant un secret partagé pour prouver son identité.

• Réception du Token d'Accès : En réponse, le serveur d'authentification envoie à l'application un "token d'accès" et parfois un "ID token". Le token d'accès permet à l'application d'accéder à certaines informations de l'utilisateur stockées par le fournisseur d'identité.

• Accès aux Ressources : L'application utilise le token d'accès pour demander des informations sur l'utilisateur auprès du fournisseur d'identité.

• Déconnexion : Une fois que l'utilisateur se déconnecte, le token d'accès devient invalide.

1 - Authentifier vos utilisateurs via ÉDIFICE

Depuis la console d'administration d’une plateforme Édifice, créer un connecteur de type OAuth 2.0

Champs à configurer :

• Identifiant : [client_Id] C'est votre identifiant oAuth2 unique pour cette intégration

•  URL : L'adresse de l'application externe à laquelle vous souhaitez accéder.

• openid : Cette option configure automatique est le scope openid pour transmettre les informations de session.

• Scope : Autorisations d'accès aux données utilisateurs de l'application externe qui doit être openid.

• Mode d'identification : Utiliser "code" pour une application web et "password" pour une application mobile.

• client_secret : Paramètre de sécurisation de l’interaction

Informations à transmettre à l'éditeur de l'application cliente :

• l'URL du récupération du code temporaire : https://domaine.ent/auth/oauth2/code

• l'URL du de la récupération du token : https://domaine.ent/auth/oauth2/token

• l'URL du de la récupération des information informations utilisateur : https://domaine.ent/auth/oauth2/userinfo

• le clientId client Id (champs "Identifiant")

• le secret (champs "Code Secret")

• le scope (champs "Scope")

2 - Tester l’accès OIDC de votre application client :

1 : Récupérer code de génération du token

Ouvrez un navigateur et entrez l'adresse adapter adaptée pour votre cas Si l'utilisateur n'est pas connecté, la plateforme Édifice redirigera automatiquement le navigateur vers la page de connexion.

Si l'utilisateur est connecté, la plateforme Édifice le redirigera ensuite vers l'URL du service avec le code de réponse inclus dans le paramètre de l'URL

• Exemple D’URL :

https://domaine.ent/auth/oauth2/auth?response_type=code&state=blip&scope=openid&client_id=duck&redirect_uri=http://duckduckgo.com

La réponse devrait être comme ceci :

https://www.duckduckgo.com/?code=9ddf3256-7e5d-4708-a121-dfbe5f6dba75&state=blip

2 - Récupérer le token

Le token d'identification, connu sous le nom d'ID Token, est l'élément central du protocole OpenID et sert à authentifier l'utilisateur. Ce token est obtenu simultanément avec le token d'accès (Access Token) lorsque le scope 'openid' est requis. Outre les champs obligatoires définis dans la section II de la spécification OpenID Connect, le token d'identification inclut également les informations suivantes :

• sub: Identifiant de l’utilisateur.

• email: L’adresse courriel de l’utilisateur, si s'il l’a renseignée.

• name: Le nom d’affichage de l’utilisateur.

À l'aide d'un client de requête HTTP tel que cURLcurl, ou d'une application plus complète comme Postman ou un équivalent, vous pouvez suivre les étapes suivantes pour obtenir le token nécessaire à la poursuite du processus d'authentification :

• Exemple sur cURL :

 curl -i -X POST -H "Authorization:Basic ZmFxMnNjaWVuY2VzOmZhcTJzY2llbmNlcy1zZWNyZXQ=" -H "Content-Type:application/x-www-form-urlencoded" -H "Accept:application/json; charset=UTF-8" -d "grant_type=authorization_code&code=9ddf3256-7e5d-4708-a121-dfbe5f6dba75&redirect_uri=http%3A%2F%2Fduckduckgo.com" https://domaine.ent/auth/oauth2/token

En cas de succès, le serveur fournira la réponse dans le format suivant :

HTTP/1.1 200 OK
      Content-Type: application/json
{
    "token_type": "Bearer",
    "access_token": "bd333cb4-b790-4b67-96e0-5e559d7717a9",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImtleSJ9.NhdGlvbi5jb20iLCJhdWQiOiJvcGVuYWJuZXIiLCJpYXQiOjE3MDgwODA0MDUsImV4cCI6MTcwODA4NDAwNX0=.QWiU47nfshO1iBkwqexb2afLrNfhGYkQ1qC3ewIzgESaLddzR8KJ4iSfwUVZsPOsQDr6Qf_eITQspPBKjf9mOpjiZVOr_KZDQ4XecxUerHCMaKiV9FJMa0r9EsTZTGItJDYH9_tUr1MHobysPYcWWTh3HnDHV1TlEOcJiuAY1h_ErvfSbMH3wxhogleOBZBWQbggm2wgPizkGLzFRCMoBG52VytUAP1qURWrUn39JRWqYz4ssTw004TD9q1wIlDpkm9NGkpunaQKjLslvpiJ81ynftmO41oaSCVi-2yo4iRspUTqhZIZy0GbynpoG-xKrnRGPT561x6ojT0GP6G1CI6m_XYeRGIRQCf9F5MiAq8lZR4vV2HkvZcB2_TtjeHH5wdnH5TD0kGIvyZpZQ-m9jVfSpavqPdU-aCoX93cAzIGdd1X1XOmL3EawQYICd6Pp9AWUjJjne8PoqD9BB0vLQ3hP4rTFyxEIlV7ZJiUfwN9y6wR6pf_Z94-brOFJRVXXTVPsBP1C0ShD6wRIEoEVUCjqalfMwgg3inpYaU8znmu9aJkeCEtiiY79KjPmW_BdMLJCYTZJGUW0v5YwJf8k1FU9NW-fpNbHtbVWk0TLAKgtk8hhbZgFNNz5TZv5BriUNg0v__fbG9gRN9WPp0XZkGqHslCmAJOXbbMIz6nG28=",
    "refresh_token": "9b01ac7a-9032-4256-808a-e7d1cfe19486",
    "expires_in": 3600,
    "scope": "openid"
}

3 : Récupération des attributs standards selon OpenID Connect

La section V de la spécification OpenID Connect détaille environ une vingtaine d'attributs standards qui peuvent être obtenus via la requête Userinfo notamment :

• sub: Son identifiant.

• name: Son nom d’affichage.

• given_name: Son prénom.

• family_name: Son nom de famille.

• preferred_username: Son nom d’affichage.

• email: Son adresse courriel.

• phone_number: Son numéro de téléphone.

Pour accéder à ces attributs, il est nécessaire d'ajouter le paramètre GET 'version=oidc1.0' à la requête habituelle.

• Exemple de commande :

curl -i -H "Authorization: Bearer 7acb83b1-53bd-4105-9b46-5acfb095158f" "https://domaine.ent/auth/oauth2/userinfo?version=oidc1.0"

La réponse devrais rediriger l’utilisateur vers votre URL avec les informations de l’utilisateur :

HTTP/1.1 200 OK
Content-Type: application/json
{
    sub: "1898a6ea-6f4e-4a43-89fa-4794f5775289"
    name: "Luck Skywalker"
    given_name:	"Luck"
    family_name: "Skywalker"
    preferred_username:	"Luck Skywalker"
    email_verified: false
    phone_number_verified: false
}

use“

3 - OIDC Back-Channel Logout et SLO

OP vers RP OIDC

Le Single Log Out (SLO) avec OpenID Connect (OIDC) est un mécanisme permettant à un utilisateur de se déconnecter simultanément de plusieurs applications et services en ligne. Cela est particulièrement utile dans les environnements où un utilisateur accède à plusieurs services ou applications qui utilisent un système d'authentification centralisé.

dans Dans la console d’administration de votre établissement, vous devrez ajouter L’URL de déconnexion pour permettre à votre système provider d’identité de vous fournir les informations de déconnexion de l’utilisateur.

1 : Réception du logout token de déconnexion utilisateur.

Après les vérifications, chaque service associé reçoit un token de déconnexion au format JWT via leur URL de déconnexion, précédemment saisie dans le panneau administrateur.

L'objet reçu est un JSON encodé en base 64 et signé avec une clé publique accessible. Il contient des informations concernant l'utilisateur qui effectue la déconnexion.

{
  logout_token: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImtleSJ9.eyJzdWIiOiIxODk4YTZlYS02ZjRlLTRhNDMtODlmYS00Nzk0ZjU3N'
}

Voici les informations qu’il contient un fois décodé :

une fois décodé :

  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "exp": 1471569754,
   "jti": "bWJq",
   "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
   "events": {
     "http://schemas.openid.net/event/backchannel-logout": {}
     }
  }

Déconnexion RP vers OP IODC

La déconnexion SLO garantit que l'utilisateur est déconnecté de tous les services associés à son identité OpenID Connect.

URL de déconnexion

POST /openid/logout/slo

Fonctionnalité

Ce point de terminaison accepte une demande de déconnexion et s’assure que l’utilisateur est déconnecté de manière sécurisée des applications connectées via OpenID Connect coté ENT.

Pré-requis

Pour initier une déconnexion, la requête doit contenir un token de déconnexion (logout_token) valide.

Dans le format suivant avec le claims obligatoires :

  {
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "exp": 1471569754,
   "jti": "bWJq",
   "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
   "events": {
     "http://schemas.openid.net/event/backchannel-logout": {}
     }
  }

Paramètres requis

• logout_token (string) : Ce token de déconnexion est requis pour confirmer votre identité et garantir que le processus de déconnexion est sécurisé.

Scénarios d'utilisation

1. Déconnexion réussie :

   • Si le token de déconnexion est valide et que le fournisseur OpenID Connect est accessible, la déconnexion sera effectuée pour toutes les sessions actives associées à cet utilisateur.

2. Erreur de requête mal formatée (400 Bad Request) :

   • Si le logout_token est absent ou incorrectement formaté, la demande sera rejetée. Assurez-vous que le token est bien fourni et qu’il correspond aux standards de OIDC https://openid.net/specs/openid-connect-backchannel-1_0.html

Exemple de requête

Voici un exemple de requête pour effectuer la déconnexion :

POST /openid/logout/slo
Content-Type: application/json

{
    "logout_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

Dans cet exemple, remplacez eyJhbGciOiJIUzI1... par votre propre token de déconnexion. Support