Voyez également : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).
Flux de code d’autorisation (spéc. : Authorisation code flow) - le flux le plus couramment utilisé, destiné aux applications Web traditionnelles ainsi qu’aux applications natives / mobiles (avec cependant des risques avec ces dernières ). Implique une redirection initiale du navigateur vers le serveur d’authentification pour l’authentification et le consentement de l’utilisateur, puis une seconde demande de l’application cliente pour récupérer le jeton d’ID.
Le diagramme de ce flux est identique à son homologue d’OAuth 2.0, la différence étant le jeton d’identification (ID Token) qui accompagne le jeton d’accès.
La signature de ce jeton offre aux serveurs de ressource protégée (RS) l’opportunité de valider le jeton localement, pourvu qu’une forme de clé leur soit connue.
Le flux de code d’autorisation offre une sécurité optimale, car :
le secret de l’application, résidant sur le serveur [1], est protégé,
les jetons ne sont pas révélés au navigateur (ne circulent que dans une liaison serveur-serveur),
l’application cliente peut être authentifiée, tout comme l’utilisateur final,
la signature du jeton lie de façon indissoluble : l’identité de l’utilisateur final, l’identité de l’application, la portée (scope) de l’autorisation.
La mise en œuvre de ce flux dans le cadre d’OAuthSD est détaillée ici : OpenID Connect : Autorisation via un code (Authorization Code Flow).
Flux implicite (spéc. : Implicit flow) - pour les applications basées sur un navigateur qui n’ont pas de backend, par exemple une application Javascript. Ce flux est également utilisé pour les applications à page unique (SinglePage Application, SPA). Le jeton d’identification est reçu directement avec la réponse de redirection de l’OP. Aucun appel au canal de retour n’est requis ici. De ce fait, le client ne peut être authentifié.
La mise en œuvre de ce flux dans le cadre d’OAuthSD est détaillée ici : Autorisation implicite.
Flux Hybride (spéc. : Hybrid Flow) - Essentiellement une combinaison du code et des flux implicites, rarement utilisé. On peut lire : "Permet à l’application front-end et back-end de recevoir des jetons séparément l’une de l’autre". Il semble plus sécurisé et tout aussi facile d’appliquer séparément un flux de code et un flux implicite.
Les flux Implicite et Hybride sont implémentés par OAuthSD mais leur usage est découragé car ils ne présentent pas les avantages de sécurité attachés à OpenID Connect :
ils compromettent le secret de l’application qui est facilement accessible au public,
ils exposent les jetons au navigateur de l’utilisateur final, ce qui rend possible une exploitation par un malware,
ils ne permettent pas d’authentifier l’application cliente.
Notes :
Les fonctionnalités d’OAuth 2.0 sont intégrées au protocole OpenID Connect. Toutes les fonctionnalités d’OAuth 2.0 et de OpenID Connect peuvent donc être atteintes par les Points d’extrémité d’OpenID Connect, en particulier les flux Client/User Credentials d’OAuth 2.0. Tous les flux sont résumés ici : OpenID Connect et OAuth 2.0 : Synthèse des flux d’autorisation (Grant Type).
Le flux Hybrid n’est que partiellement implémentée par OAuthSD. Cette méthode est peu utilisée et peut être avantageusement remplacée par une successsion d’appels aux deux premières.
RSS 2.0