Ich denke, wir haben wirklich kurz über Gitter gesprochen, und da habe ich schon gesagt, dass es auf Ihren Anwendungsfall ankommt. Ich werde einen kurzen Überblick über typische Anwendungsfälle geben und wo Sie welche Art von zusätzlicher Implementierung benötigen.
Machine to Machine Kommunikation
Wenn Sie zwei Systeme miteinander von den Backends, und diese Systeme vertrauen einander zu sprechen, können Sie die OAuth2 „Client Credentials Flow“ verwenden können. In diesem Fall gibt es keine "Endbenutzer" -Identität, nur die zwei Systeme, die sich explizit vertrauen. Für dieses Szenario ist Kong alles, was Sie brauchen - Sie fragen Kong's API-Token-Endpunkt (<address of kong>:8443/your_api/oauth2/token für URI-basiertes Routing oder fqdn.of.kong:8443/oauth2/token, wenn Sie Host-basiertes Routing verwenden) für ein Zugriffstoken mit Ihrer Client-ID und Secret und du bekommst eins zurück.
Beispiel:
curl --insecure -d 'grant_type=client_credentials&client_id=<...>&client_secret=<..>' https://<address of kong>:8443/your_api/oauth2_token
Ihre Backend-Service werden einige zusätzliche Header injiziert, wie X-Consumer-Id und X-Custom-ConsumerId erhalten, die den Verbraucher abbildet Sie in Kong erstellt.
Vertraulich Web-Anwendung mit Endbenutzers Kontext
Falls Sie Ihre API aus einer vertraulichen (= klassischen) Web-Anwendung verwenden müssen, und Sie müssen bei jedem Aufruf einen Endbenutzers Kontext haben, Sie wollen vielleicht Verwenden Sie die OAuth2-Berechtigung "Berechtigungscode". In diesem Fall benötigen Sie auch einen Autorisierungsserver, den Sie selbst implementieren müssen.
Die Aufgabe des Autorisierungsserver ist ein Ende der Benutzeridentität (mind Ihnen aufzubauen: Das ist nicht in OAuth2 festgelegt, wie dies geschehen ist, und ist an Ihnen, Sie zu einem anderen IdP verbünden können, können Sie Fragen Sie nach Benutzername und Passwort, ...) und entscheiden Sie dann, welche Rechte (= "Scopes") der Benutzer erhält, wenn er auf die API zugreift. Das liegt ganz bei Ihnen und ist Teil Ihrer Geschäftslogik, wie Sie dies entscheiden.
Der Fluss geht so:
- Sie (wieder) direkt einen Benutzer auf die Webseite des Autorisierungsserver
- Der AS authentifiziert den Benutzer (mit welchen Mitteln) und entscheidet über die Bereiche (unabhängig von der Art mit anderen Mitteln)
die AS Gespräche Kong auf zwei verschiedene Ebenen
- über den Kong Admin-API, die
provision_key der abzurufen gewünschte API
- Über den
[/your_api]/oauth2/authorize Endpunkt, den es verwendet, um einen Umleitungs-URI zu erhalten, der einen Autorisierungscode enthält, im Kontext des authentifizierten Benutzers und seines Bereichs (scope und authenticated_userid); Dieser Endpunkt zu rufen, müssen Sie response_type=code, client_id, client_secret, provision_key, authenticated_userid (was auch immer geeignet ist) und gegebenenfalls scope (Bereiche auf dem API als auch definiert werden müssen, wenn Sie diese verwenden möchten)
Falls erfolgreich, leitet die AS an der Web-Anwendung zurück, mit der Weiterleitung URI von Kong zurück
- der Web-App ruft
[/your_api]/oauth2/token Endpunkt des Kong mit seinem client_id, client_secret und code, die grant_type=code mit
Jetzt verfügen Sie über ein Zugriffstoken (und ein Aktualisierungstoken), mit dem Ihre Webanwendung im Namen des authentifizierten Benutzers auf die API zugreifen kann.
Der Autorisierungsserver muss von Ihnen implementiert werden; Das ist nicht sehr kompliziert, aber Sie müssen trotzdem sicherstellen, dass Sie wissen, wie Sie einen Benutzer authentifizieren und/oder wie Sie dies an einen anderen IdP delegieren.
Öffentliche Auftraggeber (Single-Page-Applikation) mit End User Context
Falls Sie Zugriff auf eine API von einer einzigen Seite Anwendung benötigen (wie aus einem Schräg-App oder ähnlichem), erhalten Sie bei OAuth2 „Implicit aussehen sollten Flow ", das ist ein einfacherer Fluss als die Autorisierungscode-Gewährung, hat aber andere Nachteile, wie beispielsweise die Möglichkeit, Refresh-Tokens nicht zu verwenden.
Dieser Fluss arbeitet in folgender Weise:
- Genau wie für die Gewährung Autorisierungscode Sie den Benutzer auf die Autorisierungsserver umleiten
- Die AS stellt Identität und entscheidet über Umfang (wieder einmal, diese ist bis zu Ihnen)
- der AS den authorise Endpunkt ruft, genau wie bei der Gewährung Autorisierungscode, aber diesmal mit
response_type=token
- Kong, wenn sie erfolgreich sind, wird URI welche alre zurückgeben eine Umleitung ady enthält ein Token
- Das AS leitet zurück zum SPA, indem es den Umleitungs-URI von Kong verwendet, der das Zugriffstoken im "Fragment" des URI hat (z.
https://your.app.com/#access_token=<...>&token_type=bearer&...)
Ihr SPA wird nun in der Lage sein, die Zugriffstoken verwenden, um die API zugreifen, genau wie bei der Gewährung Autorisierungscode, im Namen des authentifizierten Benutzers.
Der Nachteil dieses Ansatzes besteht darin, dass Sie das Token nicht so einfach aktualisieren können und dass es etwas weniger sicher ist als die Autorisierungscode-Berechtigung. Im Umgang mit SPAs gibt es jedoch nicht viele andere sichere Möglichkeiten, den Zugriff darauf zu delegieren.
Mobile Applications
Das letzte Szenario Ich mag würde hier berühren Mobile Anwendungen, wie Android oder iOS-Apps. Für diese kann der letzte OAuth2-Flow, die "Resource Owner Password Grant" verwendet werden. Kurz gesagt, mit dieser Zuteilung tauschen Sie die tatsächlichen Benutzerdaten (Benutzername und Passwort) gegen ein Zugriffstoken und ein Aktualisierungstoken aus, so dass Sie den Benutzernamen und das Passwort nicht mehr als vorübergehend auf dem mobilen Gerät speichern müssen.
Dieser Fluss benötigt auch einen Authorization Server, um mit Kong zu verwenden, wenn auch diesmal weniger kompliziert, obwohl Sie einen zusätzlichen token Endpunkt (zusätzlich zu dem einen Kong) implementieren müssen, was nicht der Fall ist Idealerweise in der Kong-Dokumentation beschrieben.
es so gehen würde:
- Die mobile App sein
client_id verwendet (das Geheimnis nicht, sollte das Geheimnis nicht mit der Anwendung bereitgestellt werden), die Benutzername und das Passwort zu nennen Autorisierungsserver Token Ende Punkt
- der Autorisierungsserver prüft Benutzernamen und Passwort (mittels was auch immer, wissen Sie, die Geschichte) und entscheidet über den Umfang (...)
- die AS Gespräche Kong über Admin-API erneut, die
client_secret für die zur Verfügung gestellt bekommen client_id und die provision_key für die desi rot API
Der AS gibt einen Aufruf an Kong Token Endpunkt [/your_api]/oauth2/token, wie folgt aus:
curl --insecure -d ‚grant_type = Passwort & provision_key = < ...> & client_id = < ... > & client_secret = < ...> & authenticated_userid = < ...> & scope =‘https: //: 8443/your_api/oauth2/Token
Beachten Sie, dass dieser Anruf tut nicht enthalten Benutzername und Passwort; diese gehören nicht hierher, du musst den Benutzernamen und das Passwort gegen deine eigene Identitätsquelle prüfen, Kong wird dir dabei nicht helfen.
Dieser Aufruf sollte sowohl ein Zugriffstoken als auch ein Aktualisierungstoken zurückgeben, die Sie dann (so sicher wie möglich) auf Ihrem Gerät speichern. Diese ersetzen den Benutzernamen und das Passwort, das nicht auf dem Gerät gespeichert werden muss. Das Zugriffstoken kann wie bei den anderen Endbenutzerkontextflüssen (Authorization Code Grant, Implicit Grant) verwendet werden, um im Auftrag des authentifizierten Benutzers auf die API zuzugreifen.
Ich hoffe, dass dies helfen könnte, ein wenig Licht auf, wie Sie Kong mit OAuth2 verwenden können.Es ist schwierig und involviert, aber Kong kann wirklich helfen, dies richtig zu machen und Ihre Bedenken zu trennen.