Spring security oauth2 - erste benutzerdefinierte Daten von OAuth2 AUFTRAGGEBER

Ich habe eine Website mit Spring security und Benutzer (Benutzername & Passwort) und standard-Formular-Authentifizierung. Ich Erlaube Benutzern das anlegen einer client-Id und client-secret Zusammenhang mit Ihrem Konto für die Verwendung mit einem OAuth2 gesichert-rest-API.

Verwende ich eine separate client-id & client-Geheimnis für die API und nicht Benutzername und Passwort ein, so dass die Benutzer Ihr Kennwort ändern können usw., ohne die API-Anmeldeinformationen, bestimmte Bereiche deaktivieren des API-Zugriffs etc.

Ich benutze spring-security-oauth2 (provider) zur Sicherung des rest-API und ich habe zugelassen, dass ein client-Anmeldeinformationen fließen. Ich habe setup die client-Authentifizierung für api, so dass die client-id und secret prüfen.

Aus einer separaten Anwendung verwende ich die client-id und client secret zu retreive ein access token und starten es mit der api. Zum größten Teil benutze ich simple @PreAuthorize-Ausdrücke in der Regel auf Basis einer client-Rollen und-Umfang und diese ordnungsgemäß angezeigt.

Alle oben scheint gut zu funktionieren

Aber... ich habe ein paar API-Endpunkte jetzt aber wo muss ich implementieren, einige der mehr komplexen Regeln basierend auf einige details der zugrunde liegenden Nutzer - in diesem Fall der Benutzer, generiert die client-id und secret.

Als einfaches Beispiel betrachten wir eine messaging-Anwendung, wo ich einen Endpunkt, ermöglicht es Benutzern erlaubt, eine neue "Nachricht" von einem bestimmten Typ, variieren kann. Ich habe eine Tabelle der zulässigen Empfänger für jeden einzelnen Benutzer und jeden Typ, und ich möchte, um zu überprüfen, dass die Empfänger der gesendeten Nachricht übereinstimmen, die zulässigen Empfänger für den Typ. (Benutzer dürfen Empfänger von Daten ist in der Regel nicht groß, und nur selten Veränderungen, so bin ich glücklich, speichern Sie eine Kopie der bei der Generierung einer access-token)

Bekomme ich den AUFTRAGGEBER auf diese Endpunkte und ich sehe es ist eine Instanz der OAuth2Authentication mit:

  • userAuthentication - null - Das scheint zumutbar für client-Anmeldeinformationen fließen.
  • clientAuthentication aufgefüllt und authorizationParameters enthält die grant-geben und client_id

Ich nehme an, ich könnte die client-id aus clientAuthentication.authorizationParameters nachschlagen der Benutzer und die details, die ich benötigen, aber das wären ein paar Abfragen jeder api-Aufruf, die nicht scheint Sinn zu machen.

Ich würde vermuten, es ist ein schöner Ort/Weg im Frühjahr OAuth2 libs, die während der Gewährung der access-token, das könnte ich fügen Sie einige zusätzliche details, so dass später konnte ich Sie aus der OAuth2Authentication (Haupt -) Objekt (oder etwas, das reicht?)

Alternativ gibt es einen besseren Ansatz, um eine solche Ausgabe?

Thx!!!

  • Haben Sie sah von JWT (JSON web token)? Es ist ziemlich viel ein token, das hat alle nützlichen Infos drin.
InformationsquelleAutor Mark Doyle | 2013-04-23
  1. 5

    Können Sie überschreiben die Token-Erstellung-Klasse, so wird das token selbst würde die den Benutzernamen enthalten. (vielleicht verschlüsselt an das client_secret).
    Auf diese Weise können Sie den Benutzer in Bezug auf einen token aus dem token selbst, ohne zusätzliche Datenbank zugreifen.
    Sie überschreiben sollten, 

    <bean id="tokenServices" class="org.springframework.security.oauth2.provider.token.DefaultTokenServices">

    mit Ihrer eigenen Klasse, oder verwenden Sie TokenEnhancer

    • Thx, klingt zunächst vielversprechend. Ich werde überprüfen Sie es und machen Sie einige tests in den nächsten Tag. Ich finde nicht einen Artikel/post/Probe noch so, wenn Sie bewusst lassen Sie es mich bitte wissen 🙂
    • Hi, das habe ich überprüft und es scheint, die TokenEnhancer ist nützlich, zu "verbessern" das access-token response und/oder fügen Sie einige zusätzliche Informationen ein. Aber das ist nicht das, was ich will. Es sollte keine Notwendigkeit zu senden zusätzliche Daten zurück an den client. Ich verstehe zwar deine Idee, zu versuchen, Dinge mit den Benutzernamen in das token (die ich oft brauche es nicht) es scheint mir, dass es eine bessere Möglichkeit, die Blätter Token usw unverändert und tritt nur auf der server-Seite.
    • Sie können die Informationen, die Sie benötigen, um Ihre Client-Details, wenn Sie sich registrieren, jeder client mit ClientDetails.addAdditionalInformation Als Sie kann ermittelt werden diese Informationen mithilfe der clientId Sie bekam. (dies erfordert möglicherweise eine Abfrage pro Anfrage, die scheint vernünftig zu sein)
    • Guter Punkt. Ja, der Abruf ist schade, und das, was ich vermeiden wollte. Sieht aus wie die Ausweitung Punkte/Felder, die sind nur noch nicht da. Ich habe meine eigene impl. von TokenStore, ClientDetail, ClientDetailService, aber scheint, dass ich ändern müssen, um zu viel mehr, um eine komplette Kette.
    InformationsquelleAutor achiash
  2. 6

    Warum Sie nicht verwenden Bereiche, die definiert werden können, in den client details und verwenden Sie dann ScopeVoter zu validieren, wird dieses token haben den richtigen Umfang, um auf diese Ressource zugreifen oder nicht.

    überprüfen Sie bitte meine demo für mehr details

    https://github.com/bassemZohdy/Spring_REST_OAuth_Demo

    Update 1:
    Ich habe keine Antwort zu Teil 2 deiner Frage "bekommen benutzerdefinierter Daten von OAuth2 principal" Sie können hinzufügen, rest-Dienst auf Ihrem Authorization server, die den Zugriff über OAuth-token geben Sie die erforderlichen Informationen über dieses token Benutzer, so dass Sie nicht haben, um Sorge über "OAuth2 principal" Sie sind den Umgang mit dem Autorisierungs-server als Ressourcen-server zu.

    • Thx, ich verwende einige einfache Bereiche schon, aber vermeiden, dass die Lösung, wie ich war besorgt über eine explodierende Menge der Bereiche zu erreichen, die Regeln, die ich wollte. Ich werde zu aktualisieren, die Frage mit einem Beispiel.
    • In einer anderen Lösung, die ich verwende Umfang pro Gruppe von Ressourcen, ich denke, es ist keine Einschränkung auf die Anzahl der Bereiche, Sie können auch mix-Bereiche mit Rollen.
    • Thx, ja ich benutze so ein bisschen schon. Nur für den Fall, dass ich es erwähnen würde wahrscheinlich ziemlich überwältigend zu formulieren, die Bereiche, die vom Benutzer und dann verarbeiten Sie Sie zu interpretieren 🙂 ich hatte gehofft, es gibt einen besseren Weg.
    • bitte überprüfen Sie die Update-1
    InformationsquelleAutor Bassem Reda Zohdy
  3. 5

    Meiner Meinung nach der richtige Ansatz wäre hier die Verwendung der oauth2 "Passwort" flow anstelle von client-Anmeldeinformationen. Sie können erstellen Sie eine Allgemeine client-id und client-secret und geben Sie Sie an alle Ihre Benutzer. jeder Benutzer kann als Wunsch sein eigenes token mit, diese Angaben des Kunden und seinen eigenen Benutzernamen und Passwort.
    Auf diese Weise werden alle token verbunden wäre, um eine UserDetails Objekt, das wird Ihr problem lösen.
    Sie können sehen, wie dies hier gemacht : https://labs.hybris.com/2012/06/18/trying-out-oauth2-via-curl/

    • Thx für die Idee, aber der Punkt der Verwendung von client-Anmeldeinformationen war, um die API-grundsätzlich unabhängig von den Benutzern. Nur in wenigen Fällen (Minderheit) habe ich einige komplexere Regeln. Ich habe aktualisiert die Frage zu geben, eine Begründung für die client-Anmeldeinformationen.
    • Der link hier ist kaputt. Könnten Sie bringen über einen relevanten Ausschnitt von dieser bestimmten Antwort?
    • Feste den link.
    • Link ist wieder gebrochen.
    InformationsquelleAutor achiash
Schreibe einen Kommentar