OpenID Connect OAuth Server dédié

authorize - Point d’extrémité d’autorisation (Authorization Endpoint)

https://oa.dnc.global/authorize

Le point d’entrée Authorize est le point de départ pour les flux basés sur un navigateur, tels que le flux d’autorisation ou le flux implicite.

Le serveur assure l’identification de l’utilisateur final en lui soumettant une ou plusieurs méthodes d’authentification ainsi qu’une demande d’approbation relative à l’utilisation de ses données.

Il faut distinguer (voir OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type)) :

 Les flux d’Autorisation via un code (Authorization Code Grant) qui retournent sur l’URI de retour à l’application cliente (Redirection Endpoint) un code qui permettra à cette application d’obtenir les jetons auprès du contrôleur Token. Ce type de flux permet d’authentifier l’application cliente s’il s’agit d’une application Web.
 Les flux de type Implicit ou Hybrid qui permettent d’obtenir directement les jetons. Ils ne permettent pas d’authentifier l’application cliente.

On distinguera également les flux répondant au standard OAuth 2.0 des flux OpenID Connect. Seuls les flux OpenID Connect réaliseront une authentification véritable car ils permettent d’obtenir un jeton d’identité au format JWT qui, étant signé, lie de façon sécurisée l’identité de l’utilisateur finale, celle de l’application cliente ainsi que la portée de l’autorisation.
De plus, le jeton d’identité peut être validé localement par l’application sans nécessiter de retour vers le serveur. Mais on ne peut mentionner cet avantage sans souligner que seule l’introspection permet de savoir si le jeton d’accès correspondant a été révoqué ou non.

S’agissant du jeton d’identité, OAuthSD permet d’intégrer des déclarations supplémentaires dans la charge utile du jeton JWT. Les développeurs pourront ainsi moduler les droits et privilèges de l’utilisateur final en fonction de son identité, de son appartenance ou de son profil. Un exemple particulièrement intéressant est donné par la transmission aux applications Software as Service (SaaS) des paramètres relatifs aux abonnements des souscripteurs. Une application en est donnée par le système DnC SaaS.

Dans le cadre des flux OpenID Connect, outre la fonction d’inscription unique (Single Sign On, SSO) le serveur OAuthSD implémente toutes les fonctions attendues pour le management de session : la fonction d’identification unique (Single Login Identification, SLI), la déconnexion unique (Single Login Out, SLO) ainsi que la ré-authentification silencieuse (Silent Re-Authentication, SRA), y compris avec le jeton d’identité (id_token_hint). Ceci sans modification du code d’interface des applications avec OIDC, tout étant pris en compte au niveau du contrôleur Authorize. Le Monitoring de l’état de l’authentification par les applications est également soutenu par Authorize.

token - Point d’extrémité de jeton (Token Endpoint)

https://oa.dnc.global/token

Le point d’entrée Token renvoie les jetons d’accès, les jetons d’identité et les jetons d’actualisation en fonction du type de flux et des paramètres de la demande.

Pour les flux Autorisation via un code, l’appel à Token est la deuxième étape.

Pour les flux Client Credentials, User Credentials et JWT Bearer, c’est la seule étape du flux. Ces flux ne sont définis que par OAuth 2.0 et ne retournent pas de jeton d’identité.

Notes :
 OAuthSD permet aux applications publiques d’obtenir les jetons sans dévoiler le secret de l’application avec le Flux de code d’autorisation + PKCE.
 Aucun flux défini par OpenID Connect ne s’adresse directement à Token.
 Les flux implicites définis par OAuth 2.0 comme par OpenID Connect permettent d’obtenir les jetons à l’appel d’Authorize.
 Certains auteurs définissent dans le cadre d’OAuth 2.0 un flux "Refresh Token Grant" s’adressant au point d’extrémité de jeton. Il ne s’agit pas à proprement parler d’un flux puisque, prolongeant un flux d’autorisation établi précédemment, il ne peut exister de façon autonome. Voir : Rafraîchir (actualiser) un jeton d’accès.

introspect - Point d’extrémité d’introspection (Introspection Endpoint)

https://oa.dnc.global/introspect

Une application ou une ressource protégée recevant un jeton doit toujours le valider avant de poursuivre son processus.

Le point d’entrée Introspection détermine l’état actif et les méta-informations d’un jeton. Le document RFC 7662 définit l’introspection pour un jeton d’accès dans le cadre d’OAuth 2.0.
OAuthSD étend l’introspection au jeton d’identité ID Token (au format Json Web Token, JWT) défini par OpenID Connect ainsi qu’aux jetons d’identité cryptés (au format Json Web Encryption JWE).

Notes :
 Un jeton d’accès ne peut être validé localement et ne peut l’être que par introspection.
 En revanche, un jeton d’identité (qui est signé cryptographiquement) peut aussi être validé localement. Cependant l’introspection permet de savoir si le jeton n’a pas été révoqué.
 L’utilisateur final désigné par la déclaration sub du JWT, ou sujet (subject), est considéré comme connecté par OAuthSD s’il existe un access_token valide (non expiré) pour ce sujet et le client au moment de l’introspection.

userinfo - Point d’extrémité d’informations sur l’utilisateur final (UserInfo)

https://oa.dnc.global/userinfo

Le point d’entrée UserInfo est une ressource protégée qui retourne des informations sur l’utilisateur final qui est le sujet de l’authentification.
Les demandes adressées au point de terminaison UserInfo doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token).
En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification.
S’agissant d’une spécification d’OpenID Connect, l’application appelante doit avoir été enregistrée avec le scope réservé ’openid’.

Une idée directrice du standard OpenID Connect est de demander à l’utilisateur final son accord (grant) pour l’utilisation de ses données personnelles. La réponse UserInfo est donc modulée par les portées d’autorisation (Scopes) demandées et accordées.

Puisque nous parlons des portées d’autorisation, il est malheureux de constater que le terme "Scope" couvre différentes réalités.

logout - Point d’extrémité de déconnexion (Logout Endpoint)

https://oa.dnc.global/logout.php

Le point d’entrée Logout permet de déconnecter un utilisateur au niveau du serveur d’authentification en effaçant tous les jetons d’accès qui lui sont associés. En une seule opération (Single Logout, SLO), l’utilisateur pourra déconnecter toutes les applications sur tous les terminaux à partir desquels il était connecté, ainsi que les applications qui auraient été connectées en son nom. Cependant, pour que cela fonctionne, il faut que les applications interrogent le serveur d’authentification, soit par introspection des jetons, soit par Monitoring.

Les demandes de déconnexion adressées au point de terminaison Logout doivent être authentifiées à l’aide du jeton d’identité obtenu au moment de l’authentification du client considéré.
S’agissant d’une extension d’OpenID Connect, l’application appelante doit avoir été enregistrée avec le scope réservé ’openid’.

Notons que le serveur OAuthSD exécute immédiatement la déconnexion si le jeton d’identité est valide. Un éventuel dialogue de confirmation devrait être géré côté client dans le cadre de la fonctionnalité "Monitoring".

revoke - Point d’extrémité de révocation (Revocation Endpoint)

https://oa.dnc.global/oauth/revoke.php

Le point d’entrée Revoke permet d’invalider un jeton d’accès ou de rafraîchissement.
Le jeton d’identité associé au jeton d’accès sera également invalidé.
Cependant, une application ne pourra le savoir que si elle valide les jetons par introspection ou par Monitoring.

Notons que la déconnexion (Logout) implique une révocation de tous les jetons de l’utilisateur final considéré.

keys - Point d’extrémité d’informations sur les clefs (Keys Endpoint)

https://oa.dnc.global/keys

Le point d’entrée Keys est une ressource protégée qui renvoie un jeu de clés Web JSON (JWKS) qui contient les clés publiques qui pourront être utilisées par un client pour vérifier la signature d’un jeton d’identité.

Les demandes adressées au point de terminaison Keys doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token).

Notons qu’OAuthSD expose localement un contrôleur Updatekeys qui renouvelle automatiquement toutes les paires de clés publiques/privées. Ce contrôleur, par exemple, pourra être évoqué régulièrement par une tâche CRON.

resource - Point d’extrémité de ressource (Resource Endpoint)

https://oa.dnc.global/oauth/resource.php
Le point d’entrée Resource [2] renvoie des informations sur le jeton d’accès qui lui est adressé, dont sa validité.
Le client effectuant la demande ne nécessite pas d’authentification.

Découverte des points d’entrée

Conformément à la spécification OpenID Connect Discovery 1.0, OAuthSD expose ses métadonnées à l’URI :

Ce sujet est traité plus en détail ici : API OpenID Connect : Découverte.

Pour tester le serveur OAuthSD avec vos applications :
 Inscrivez-vous comme auteur d’applications
 Lier une application cliente au serveur OAuthSD

 
A propos d’OAuthSD v2 :
OAuthSD offre maintenant un jeu unique de points d’entrée. OIDC étant construit sur OAuth 2.0, l’idée directrice est que l’approche "par le haut" depuis OIDC simplifie considérablement la compréhension.