So können Sie Benutzeraktionen mit Laravel Passport-Scopes + Password Grant Type einschränken

8

Ich habe das Paket Laravel Passport für Laravel 5.3 so eingerichtet, wie es in der offiziellen Dokumentation beschrieben ist ( Ссылка ).

Ich möchte, dass die API von einer mobilen Anwendung genutzt wird. Daher versuche ich, Password Grant Tokens zu implementieren. Ich habe einen Passwort-Bewilligungs-Client und den Token-Anfrage-Prozess erstellt ...

%Vor%

... Funktioniert wie erwartet und gibt einen Zugriffstoken und einen Aktualisierungstoken für einen meiner Benutzer zurück.

Aber jetzt möchte ich einige Bereiche definieren, damit ich den Zugriff von Benutzern einschränken kann ... Wenn ich die Dokumentation erneut befolge, habe ich sie in boot Methode von AuthServiceProvider.php wie:

%Vor%

Wenn in diesem Szenario ein "böswilliger" normaler Benutzer ein Token (mit dem obigen POST-Aufruf) anforderte, indem er 'scope' => 'admin' anwählte, würde er oder sie ein Admin-Token erhalten ... und das ist nicht das, was ich möchte.

Ich möchte also wissen, wie der Workflow in dieser Situation den Zugriff auf normale Benutzer effektiv einschränkt, und wo muss ich die Scope-Validierungslogik implementieren .

Vielen Dank im Voraus.

    
andcl 21.12.2016, 13:13
quelle

2 Antworten

2

Eine Möglichkeit, dies zu tun, wäre eine Middleware zu erstellen.

Wenn Sie beispielsweise nur Benutzer mit einer E-Mail von example.com wünschen, die die Administrator-Domain anfordern, können Sie so etwas tun

Beispiel ScopeLogic.php Middleware:

%Vor%

Natürlich müssen Sie diesen Bereich zu Ihrem $ routeMiddleware-Array in der Kernel.php

hinzufügen %Vor%

Sowie wrap Passport::routes() in AuthServiceProvider.php , um nach dieser Middleware zu suchen

%Vor%

Passport überprüft auch, ob eine richtige Kombination aus Benutzername und Pass angegeben wurde, damit Sie sich in der Middleware keine Gedanken darüber machen müssen

    
Mauricio Trajano 23.04.2017 01:05
quelle
0

Ich denke, was die meisten Leute mit OAuth und APIs verwirrt, ist, dass Bereiche an "Clients" gebunden sind und nicht an den "Ressourcenbesitzer" selbst. Clients sollten in der Lage sein, mit einer API zu sprechen, indem sie einen Admin-Bereich oder bei Bedarf keine Bereiche verwenden. Wenn sie einen Bereich vom Typ "Admin" zusammen mit einem Benutzerkontext verwenden (Kennwortzuweisung, Berechtigungscodezuweisung usw.), kann sie nicht daran gehindert werden, Aufrufe zu tätigen, die einen solchen Bereich für diesen Benutzer in der API erfordern. Für mich ist die einzige Person, die wirklich als bösartig eingestuft werden kann, derjenige, der es schafft, ein Zugriffs-Token zu stehlen, das einen Admin-Bereich enthält. Aus diesem Grund dürfen API-Implementierer angeben, welche Gültigkeitsbereiche einem Client gewährt werden sollen. Wenn es sich um eine First-Party-Anwendung handelt, die etwa die Kennwortvergabe verwendet, haben Sie als Benutzer keine andere Wahl, als Ihren Daten zu vertrauen.

Ich weiß nicht, wie man das macht und das abgerufene Token in der mobilen App eines anderen benutzt, aber wenn Sie selbst ein Token manuell mit einem Admin-Bereich anfordern, dann sehe ich wirklich nichts falsches (außer Sie geben der App mehr Kontrolle über Sie als Benutzerkontext festgelegt, so dass es sogar kontraproduktiv sein kann?)

Wenn Sie mehr Kontrolle benötigen, müssen Sie über Ihre API gehen und so etwas wie Berechtigungen auf Anwendungsebene für jeden Benutzer in Ihrem Ressourcenserver erstellen.

    
georaldc 28.06.2017 16:29
quelle