Rejestracja użytkownika dla API/SPA

Question

Tworzę interfejs API i osobną aplikację typu front-end, która pobiera wymieniony interfejs API. W moim konkretnym przypadku używam Laravel Passport dla mojego API i niektórych VueJS dla mojej aplikacji frontendowej.

Aby użytkownik mógł utworzyć konto, użytkownik musi POST do trasy (/oauth/token) na API, które wymaga client_secret zostać przekazana (https://laravel.com/docs/5.3/passport#password-grant-tokens).

Jedynymi opcjami widzę to:

1. posiadające client_secret wysłany jako nagłówek z mojego frontend aplikacji. Jednak wystawienie tego tokena na otwartej przestrzeni nie wydaje się mądre.
2. Nie wymagają w ogóle client_secret. To nie wydaje się dużo lepsze niż opcja 1.
3. Masz dynamiczną stronę na mojej aplikacji frontendowej, która może bezpiecznie przechowywać client_secret, a następnie wysłać ją do API. Chociaż jest to oczywiście najbezpieczniejsze, wydaje się, że częściowo pokonało to cel w pełni statycznej nakładki (SPA).

Jaka jest najlepsza praktyka dla tego rodzaju podejścia? Szukałem, jak to się robi w ogóle z API i SPA, ale nie znalazłem niczego, co wskazywałoby mi właściwy kierunek.

Answer 1

Natknąłem się na ten sam problem i nie znalazłem więcej dokumentacji dotyczącej problemu.

Oto, co zrobiłem, wydaje mi się, że działa świetnie, powiesz mi, jeśli zauważysz coś nie tak.

W przypadku moich aplikacji będę używać klientów do przydzielania haseł, które będę tworzyć w locie dla każdego "klienta" mojej aplikacji. Przez klienta mam na myśli przeglądarkę, aplikację mobilną lub cokolwiek innego.

Każda przeglądarka sprawdza przy starcie, czy ma jakiekolwiek id_klienta i client_secret w localStorage (lub ciasteczka lub cokolwiek). Następnie, jeśli nie, wywołują punkt końcowy interfejsu API, który utworzy klienta udzielającego haseł i zwróci informacje do przeglądarki.

Przeglądarka będzie mogła zalogować użytkownika za pomocą tej nowej informacji o kliencie i jego danych uwierzytelniających.

Oto kontroler użyć do tworzenia klienta hasło Grant:

<?php 

namespace App\Http\Controllers\Api; 

use App\Http\Controllers\Controller; 
use Illuminate\Contracts\Hashing\Hasher; 
use Illuminate\Http\Request; 
use Laravel\Passport\ClientRepository; 

class AuthController extends Controller 
{ 
    protected $hasher; 

    protected $clients; 

    public function __construct (Hasher $hasher, ClientRepository $clients) 
    { 
     $this->hasher = $hasher; 
     $this->clients = $clients; 
    } 

    public function makeClient (Request $request) 
    { 
     $client = $this->clients->create(null,$request->header('User-Agent','Unknown Device'), '', false, true); 

     return $client->makeVisible('secret'); 
    } 
} 

Jak widać, jako nazwa dla klienta, staram się zachować User-Agent przeglądarki internetowej. Mogę potencjalnie wyświetlić stronę mojemu użytkownikowi z wszystkimi jego klientami i przyznać mu prawo do odwołania niektórych klientów, takich jak:

"Google Chrome, Nowy Jork". Możesz również przechowywać adres IP klienta lub cokolwiek, co pomoże ci dokładniej zidentyfikować typ urządzenia klienta ...

Answer 2

Z mojego punktu widzenia składnik Passport Laravel wydaje się nieprawidłowo implementować protokół ramowy OAuth2.

Parametry client_id i client_secret nie są częścią typu dotacji. W przypadku typu przydziału kwalifikatora właściciela zasobów, wymagane są następujące parametry: username i password (patrz RFC6749 section 4.3.2).

client_id i client_secret służą do uwierzytelniania poufnego klienta, który wysyła swoje poświadczenia za pomocą parametrów dotyczących ciała (patrz RFC6749 section 2.3.1). Składnik Laravel Passport powinien zezwalać na inne schematy uwierzytelniania klientów (w szczególności Podstawowy system uwierzytelniania HTTP). RFC6749 wskazuje również, że

Łącznie poświadczeń klienta w żądaniu ciała z użyciem dwóch parametrów nie jest zalecane i powinno być ograniczone do klientów niezdolnych bezpośrednio wykorzystać HTTP podstawowy schemat uwierzytelniania

Specyfikacja OpenID Connect Core wymienia niektóre z tych schematów w its section 9. Dokument RFC6749 nie wskazuje, w jaki sposób klienci publiczni (na przykład SPA) powinni uwierzytelniać się względem punktu końcowego tokena. Mają korzystać z typu grantu Implicit, który nie wymaga uwierzytelnienia klienta.

W każdym razie rozwiązaniem może być użycie pewnego rodzaju proxy. To proxy musi być zainstalowane na serwerze. Otrzyma wszystkie żądania od SPA (bez tajemnicy klienta), doda tajny klient i przekaże zmodyfikowane żądanie do punktu końcowego Laravel Passport. Następnie odpowiedź jest wysyłana do SPA. W ten sposób SPA nigdy nie ujawnia tajemnicy klienta.

Answer 3

Prostszym sposobem byłoby zajęcie się rejestracją użytkownika za pomocą aplikacji Laravel z uruchomionym Passport (a nie za pomocą interfejsu API aplikacji Vuejs).
Po zarejestrowaniu użytkownika i zalogowaniu się można użyć oprogramowania pośredniego Passport CreateFreshApiToken, aby dodać token do pliku cookie użytkownika podczas ładowania aplikacji frontendowej. Koniec z problemem client_secret.

Zobacz https://laravel.com/docs/5.3/passport#consuming-your-api-with-javascript i https://mattstauffer.co/blog/introducing-laravel-passport#super-powered-access-to-the-api-for-frontend-views

oauth/token także nie stwarza użytkownikowi wierzę? Ma dostarczać token (dla klienta akceptującego hasła) lub kod autoryzacyjny (klient udzielający zezwolenia na kod autoryzacyjny).