Administrateur (d’applications), Auteur (propriétaire d’applications)
Un développeur ou un propriétaire de sites Web, utilisateur privilégié, notamment propriétaire d’une ou plusieurs applications clientes qu’il a inscrites sur ce serveur en vue de déléguer les authentifications.
Notes :
cette notion est propre au serveur OAuthSD de DnC.
il s’agit également d’un objet Auteur au sens de SPIP.
Autorisation
Requête de la part d’une application cliente vers :
soit une personne (utilisateur final) à qui il est demandé d’autoriser ou de refuser l’accès à une ressource.
soit une machine dans le cas de l’autorisation serveur à serveur.
Client, Application cliente
Un Client est une application inscrite sur ce serveur par un administrateur. Plutôt que de réaliser elle-même l’authentification des utilisateurs, l’application cliente délègue cette action au serveur OAuth. Cela permet également d’autoriser l’accès aux ressources protégées appelées par cette application.
Dans le contexte OpenID, un client est dénommé Relying Party (RP).
Diagramme de Flux (Flow Chart), Flux d’Autorisation (Grant Flow)
Représentation graphique de la séquence des échanges entre les Rôles. Il existe un Diagramme de Flux distinct pour chacun des 4 types d’Autorisation ou Flux.
Type d’Autorisation (Grant Type)
OAuthSD prend en charge plusieurs types d’autorisation, qui sont des méthodes permettant d’obtenir des jetons d’accès (valeurs de chaîne représentant les autorisations accordées). Différents types d’autorisation autorisent différents types d’accès et, en fonction des besoins de votre application et la nature des ressources, certains types d’autorisation sont plus appropriés que d’autres. Mais attention : tous ne sont pas parfaitement sécurisés !
Jeton (Token)
Le jeton est une chaine de caractères générée par le serveur d’autorisation. Il est émis en réponse à une demande de l’application cliente.
Dans le cadre de OAuth 2.0, on distingue 2 types de jetons :
Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation.
Le jeton de renouvellement (Refresh Token ) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.
Le protocole OpenID Connect ajoute :
Le jeton d’identité (ID Token). De type JSON Web Token, ce jeton transporte des données relatives à l’authentification : application cliente, identité et profil de l’utilisateur final, étendue de l’autorisation. Étant crypté et signé, il offre un moyen sûr de transmettre aux ressources protégées des informations fiables sur l’authentification : utilisateur final, application, portée de l’autorisation.
Rôles
Les protocoles d’authentification de OAuth définissent les échanges entre 4 rôles :
Le détenteur des données (Ressource Owner) : une ressource matérielle, ou une personne (Utilisateur Final), qui autorise l’accès à une ressource protégée.
Le serveur de ressources (Ressource Server, RS) : serveur qui héberge les ressources protégées, et répond aux demandes d’accès aux ressources protégées selon le jeton d’accès (Access Token) ou d’identité (ID Token).
Dans le contexte OpenID, le serveur de ressource peut recevoir un jeton d’identité (ID Token) lui permettant d’authentifier l’utilisateur, l’application cliente et les autorisations exprimées par les portés d’autorisation (scopes).
Le Client ou l’Application Cliente (Client, Client Application) : application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Le client est inscrit sur le serveur d’autorisation par un administrateur d’application qui en configure les caractéristiques.
Dans le contexte OpenID, un client est dénommé Relying Party (RP) ou partie de confiance.
Le Serveur d’autorisation (Authorization Server, AS) : serveur qui délivre des jetons d’accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part.
Dans le contexte OpenID, le serveur d’autorisation délivre un jeton d’identification (ID token) en réponse à une demande d’authentification, ce qui justifie la dénomination OpenID Provider (OP ou IdP).
Etendue (ou portée) de l’autorisation (Scope)
Les Scopes définissent l’étendue des droits ( les actions permises sur les données de la ressource ) attachés au token d’accès. La liste des Scopes disponibles est définie par l’Auteur pour chacune de ses applications clientes du côté du serveur d’autorisation. La signification d’un scope dépend exclusivement de ce que le serveur de ressources protégées en fait (ou n’en fait pas), le serveur d’autorisation étant transparent à cet égard.
Ressource protégée
D’une façon générale, tout type de ressource capable de produire des données et dont l’accès est contrôlé.
En particulier, un serveur de ressources (Ressource Server, RS) est un serveur qui héberge les ressources protégées, et répond aux demandes d’accès aux ressources protégées selon le jeton d’accès (Access Token) ou d’identité (ID Token).
Dans le contexte OpenID, le serveur de ressource peut recevoir un jeton d’identité (ID Token) lui permettant d’authentifier l’utilisateur, l’application cliente et les autorisations exprimées par les portés d’autorisation (scopes).
URI de redirection (Redirect URI)
Une URI absolue de l’application cliente à laquelle le serveur redirige l’user-agent de l’utilisateur final à la suite du processus d’authentification, et à laquelle il adresse le résultat.
Utilisateur, utilisateur final (End User)
Internaute répondant aux requêtes d’authentification. Ses identifiants sont inscrits sur le serveur d’authentification (et non du côté des applications clientes).