OAuth 2: Trennung von Ressourcen-server und authorization server

Den OAuth 2 spec führt mich zu glauben, dass die "Ressource server" und "authorization server" nicht unbedingt die gleiche Anwendung, aber ich bin kämpfen, um herauszufinden, wie diese tatsächlich in die Praxis umgesetzt.

Als ein Beispiel angenommen, die folgenden apps vorhanden:

resource server
authorization server
web-frontend
third-party-client-app

Szenario #1: einloggen im web-frontend

Benutzer gibt seine login-Formular
web-app Beiträge Anmeldeinformationen, um die auth-server (grant_type=Passwort) und erhält ein access_token
die web-app speichert den access_token in einer Sitzung
bei jeder nachfolgenden Anfrage:
- BEKOMMEN Ressource(N) aus dem resource server (w/access_token im Authorization-header) und render es in der web-frontend -
- wenn wir einen 401-dann melden Sie den Benutzer aus (entfernen access_token aus der Sitzung)

Szenario #2: Autorisieren third-party-app

Benutzer fordert eine Autorisierung von der auth-service
erlauben/verbieten Formular angezeigt wird
Benutzer umgeleitet wird zurück zum client app mit dem Autorisierungs-code vorhanden
client-app-POSTs-code auth-service (grant_type=authorization_code) und erhält ein access_token
Kunde Erhält Ressourcen aus dem Ressourcen-server übergibt (w/Auth-header)

Den Teil, den ich habe Schwierigkeiten zu verstehen, ist, wie um den Benutzer zu authentifizieren, bevor Sie sehen, die erlauben/verweigern form im Szenario #2. Der Benutzer protokolliert werden kann, in der Haupt-web-app aber der auth-service hat keine Ahnung und würden es auch irgendwie brauchen, um den Benutzer zu authentifizieren wieder. Funktioniert die auth-Dienst unterstützen müssen login/sessions, wie gut?

Frage ich mich, ob es vielleicht mehr Sinn machen, für die web-app zu sein, die verantwortlich für die Anzeige der allow/deny-form aus zwei Gründen:

es hält alle von der Benutzeroberfläche in einer einzigen app
würde nicht erzwingen, dass der Benutzer erneut seine oder Ihre Anmeldeinformationen, wenn Sie nicht bereits angemeldet sind, um die web-app

Hier ist eine mögliche alternative zu Szenario #2:

Benutzer fordert eine Autorisierung von web-app
erlauben/verbieten Formular angezeigt wird
web-app Beiträge zu auth-server erstellen eines neuen grant -, Autorisierungs-code wird zurückgegeben,
web-app leitet Sie an die client-app, mit auth-code vorhanden
client-app-POSTs-code auth-Dienst und erhält access_token

Was ist der beste Weg, dies zu behandeln? Allgemeine Kommentare, Empfehlungen, etc. wäre genial!

Dank

InformationsquelleAutor scttnlsn | 2013-04-26

4

Ihrem alternativen Szenario ist wahrscheinlich das, was Sie mit zu gehen: wenn Sie wirklich, wirklich wollen, um zu trennen, Ihr fließt aus, Sie könnten versuchen, so etwas wie dieses:
1. Benutzer fordert eine Autorisierung von auth-Dienst im Auftrag von service-mit grant_type=code
2. auth-Dienst erkennt der Benutzer ist nicht eingeloggt: Umleitung der web-Anwendung mit einem parameter request fragt der web-server zu senden user zurück.
3. web app speichert die parameter request, fragt dann nach Benutzername/Passwort
4. web-app Beiträge Anmeldeinformationen, um die auth-server (grant_type=Passwort) und erhält ein access_token.
5. die web-app speichert den access_token in einer Sitzung
6. die web-app erzeugt ein signiertes token erfassen der Benutzer-id und leitet Sie zurück zu auth-service mit signierten token als parameter request
7. die auth-Dienst analysiert signierte token, Auszüge Benutzer-id, displays erlauben/verbieten form
8. Benutzer umgeleitet wird zurück zum client app mit dem Autorisierungs-code vorhanden
9. client-app-POSTs-code auth-service (grant_type=authorization_code) und erhält ein access_token
10. Kunde Erhält Ressourcen aus dem Ressourcen-server übergibt (w/Auth-header)
- Danke! Das ist ein interessanter Ansatz. Noch unsicher ist, ob es sich lohnt, die zusätzliche Komplexität.
- Ja, es ist eine Frage, die es gibt: wenn Sie haben eine Menge verschiedener web-apps unter Verwendung der gleichen auth-backend (wie Google es tut), Sie wahrscheinlich wollen eine dedizierte auth-server mit allen zugehörigen login-screens auf Sie. Für eine einzelne app, lohnt sich wahrscheinlich nicht die Arbeit.
- Passwort geben Typ sollte nur für Anwendungen verwendet werden, im Besitz und kontrolliert von der Person, die Eigentümer der Autorisierungs-service. Ansonsten öffnet es gravierende Sicherheitslücken. Ein Benutzer sollte erst Ihre Anmeldeinformationen eingeben, um die Anwendung, die Sie ausgestellt hat.
InformationsquelleAutor Femi
5

OAauth2 framework docs : https://tools.ietf.org/html/rfc6749

(A) fordert Der client ein access token durch Authentifizierung mit der
authorization server und präsentiert eine Genehmigung erteilen.

(B) Der Autorisierungs-server authentifiziert den client und überprüft
die Berechtigung zu gewähren, und, wenn gültig, gibt eine access-token
und einen refresh-token.

(C) Der client stellt eine geschützte Ressource-Anforderung an die Ressource
server durch die Vorlage der access token.

(D) Der Ressource server überprüft das access-token, und, wenn gültig,
die Anforderung erfüllt.

(E) die Schritte (C) und (D) wiederholen Sie, bis der access-token abläuft. Wenn die
Kunde weiß, dass das access-token ist abgelaufen, springt zu Schritt (G);
ansonsten macht es einen geschützten Ressource anfordern.

(F), Da die access-token ungültig ist, wird die Ressource server gibt
ein invalid token Fehler.

(G) fordert Der client ein neues token für den Zugriff durch Authentifizierung mit
der Autorisierungs-server und präsentiert die refresh-token. Die
client-Authentifizierung, Anforderungen basieren auf dem client-Typ
und auf den Autorisierungs-server-Richtlinien.

(H) Der Autorisierungs-server authentifiziert den client und überprüft
der refresh-token, und wenn Sie gültig ist, Fragen Sie eine neue access-token (und
Optional, ein neues refresh token).

InformationsquelleAutor Rzv Razvan

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.