OAuth 2: séparation du serveur de ressources et du serveur d'autorisation
La spécification OAuth 2 me porte à croire que le "serveur de ressources" et le "serveur d'autorisation" ne doivent pas nécessairement être la même application, mais j'ai du mal à comprendre comment cela est réellement mis en œuvre en pratique.
Par exemple, supposons que les applications suivantes existent:
- serveur de ressources
- serveur d'autorisation
- interface web
- application cliente tierce
Scénario n ° 1: connexion à l'interface Web
- l'utilisateur soumet un formulaire de connexion
- les informations d'authentification POST de l'application Web sur le serveur d'authentification (grant_type = password) et reçoivent un access_token
- l'application web stocke le access_token dans une session
- à chaque demande ultérieure:
- OBTENEZ des ressources à partir du serveur de ressources (avec access_token dans l'en-tête d'autorisation) et rendez-les dans l'interface Web
- si nous obtenons un 401, déconnectez l'utilisateur (supprimez access_token de la session)
Scénario n ° 2: autorisation d'une application tierce
- l'utilisateur demande l'autorisation au service d'authentification
- le formulaire autoriser/refuser est affiché
- l'utilisateur est redirigé vers l'application cliente avec le code d'autorisation présent
- le code POST de l'application cliente au service d'authentification (grant_type = autorisation_code) et reçoit un access_token
- client obtient des ressources du serveur de ressources passant (avec en-tête Auth)
La partie que j'ai du mal à comprendre est de savoir comment authentifier l'utilisateur avant d'afficher le formulaire d'autorisation/de refus dans le scénario # 2. L'utilisateur peut être connecté à l'application Web principale, mais le service d'authentification n'en a aucune idée et devra en quelque sorte authentifier à nouveau l'utilisateur. Le service d'authentification doit-il également prendre en charge la connexion/les sessions?
Je me demande s'il serait plus logique que l'application Web soit responsable de l'affichage du formulaire d'autorisation/refus pour deux raisons:
- il conserve toute l'interface utilisateur dans une seule application
- ne forcerait pas l'utilisateur à soumettre à nouveau ses informations d'identification s'il est déjà connecté à l'application Web
Voici une alternative possible au scénario # 2:
- l'utilisateur demande l'autorisation à une application Web
- le formulaire autoriser/refuser est affiché
- pOST de l'application Web sur le serveur d'authentification créant une nouvelle autorisation, le code d'autorisation est renvoyé
- l'application Web redirige vers l'application cliente avec le code d'autorisation présent
- client POST code pour authentifier le service et reçoit access_token
Quelle est la meilleure façon de gérer cela? Tout commentaire général, conseil, etc. serait génial!
Merci
Votre scénario alternatif est probablement celui avec lequel vous voulez aller: si vous voulez vraiment vraiment séparer vos flux, vous pouvez essayer quelque chose comme ceci:
- l'utilisateur demande l'autorisation du service d'authentification au nom du service avec grant_type = code
- le service d'authentification se rend compte que l'utilisateur n'est pas connecté: redirige vers l'application Web avec un paramètre de demande demandant au serveur Web de renvoyer l'utilisateur.
- paramètre de demande des magasins d'applications Web, puis demande le nom d'utilisateur/mot de passe
- les informations POST de l'application Web sur le serveur d'authentification (grant_type = password) et reçoivent un access_token.
- l'application web stocke le access_token dans une session
- l'application Web génère un jeton signé capturant l'ID utilisateur et redirige vers le service d'authentification avec un jeton signé comme paramètre de demande
- le service d'authentification analyse le jeton signé, extrait l'ID utilisateur, affiche le formulaire d'autorisation/refus
- l'utilisateur est redirigé vers l'application cliente avec le code d'autorisation présent
- le code POST de l'application cliente au service d'authentification (grant_type = autorisation_code) et reçoit un access_token
- client obtient des ressources du serveur de ressources passant (avec en-tête Auth)
Documents sur le cadre OAauth2: https://tools.ietf.org/html/rfc6749
(A) Le client demande un jeton d'accès en s'authentifiant auprès du serveur d'autorisation et en présentant une autorisation.
(B) Le serveur d'autorisation authentifie le client et valide l'octroi d'autorisation et, s'il est valide, émet un jeton d'accès et un jeton d'actualisation.
(C) Le client fait une demande de ressource protégée au serveur de ressources en présentant le jeton d'accès.
(D) Le serveur de ressources valide le jeton d'accès et, s'il est valide, sert la demande.
(E) Les étapes (C) et (D) se répètent jusqu'à expiration du jeton d'accès. Si le client sait que le jeton d'accès a expiré, il passe à l'étape (G); sinon, il fait une autre demande de ressource protégée.
(F) Étant donné que le jeton d'accès n'est pas valide, le serveur de ressources renvoie une erreur de jeton non valide.
(G) Le client demande un nouveau jeton d'accès en s'authentifiant auprès du serveur d'autorisation et en présentant le jeton d'actualisation. Les exigences d'authentification client sont basées sur le type de client et sur les politiques du serveur d'autorisation.
(H) Le serveur d'autorisation authentifie le client et valide le jeton d'actualisation et, s'il est valide, émet un nouveau jeton d'accès (et, éventuellement, un nouveau jeton d'actualisation).