Social login w Laravelu z Socialite

3 min. czytaniaZaktualizowano

Socialite wykonuje redirect OAuth i zwraca tożsamość dostawcy; aplikacja posiada linkowanie kont, bezpieczeństwo sesji i odzyskanie dostępu. Konfiguruj callback URL per środowisko, a klikologię konsol dostawców trzymaj w appendixie, bo zmienia się częściej niż kod.

php
<?php

declare(strict_types=1);

return [
    'google' => ['client_id' => env('GOOGLE_CLIENT_ID'), 'client_secret' => env('GOOGLE_CLIENT_SECRET'), 'redirect' => env('GOOGLE_REDIRECT_URI')],
    'facebook' => ['client_id' => env('FACEBOOK_CLIENT_ID'), 'client_secret' => env('FACEBOOK_CLIENT_SECRET'), 'redirect' => env('FACEBOOK_REDIRECT_URI'), 'graph_version' => env('FACEBOOK_GRAPH_VERSION', 'v24.0')],
];

W callbacku najpierw dopasuj niezmienne ID dostawcy. E-mail może nie istnieć, zmienić się lub należeć do konta hasłowego, więc linkowanie wymaga ścieżki potwierdzenia przez zalogowanego użytkownika. Gdy schema wymaga hasła dla social-only usera, wygeneruj je, nie używaj przewidywalnego placeholdera.

php
<?php

declare(strict_types=1);

use Illuminate\Support\Str;

$user = User::query()->firstOrCreate(['email' => $providerUser->getEmail()], ['name' => $providerUser->getName() ?? 'New user', 'password' => Str::password(40)]);

Tokeny dostawcy przechowuj zaszyfrowane tylko, gdy późniejsze API ich potrzebuje; żądaj minimalnych scopes i zapewnij disconnect oraz drugą metodę logowania przed usunięciem ostatniej tożsamości. Waliduj OAuth state, zostaw CSRF middleware, limituj wejścia i nie loguj tokenów.

Tożsamość dostawcy to nie email

Email może nie istnieć, zmienić się lub należeć do konta hasłowego. Zapisuj niezmienny identyfikator dostawcy w osobnej tabeli z unikalnym (provider, provider_id), a nowe połączenie dodawaj tylko po potwierdzeniu przez zalogowanego użytkownika.

php
<?php

declare(strict_types=1);

use Illuminate\\Database\\Schema\\Blueprint;
use Illuminate\\Support\\Facades\\Schema;

Schema::create('social_identities', function (Blueprint $table): void {
    $table->id();
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->string('provider');
    $table->string('provider_id');
    $table->text('access_token')->nullable();
    $table->unique(['provider', 'provider_id']);
});

Callback powinien korzystać ze stateful drivera Socialite i najpierw odnaleźć provider ID. Brak zweryfikowanego emaila prowadzi do completion flow, nie automatycznego merge. Str::password() jest sensowny tylko gdy schema nadal wymaga hasła; UserObserver tworzy profil tak samo jak przy innych rejestracjach.

Szyfruj token wyłącznie, gdy późniejsze wywołanie API go potrzebuje, ogranicz scopes, nie loguj tokenów i zapewnij disconnect oraz inną drogę odzyskania konta. Testuj Socialite::fake() dla odmowy, braku emaila i istniejącego konta. Wersję Graph API trzymaj w konfiguracji i aktualizuj według harmonogramu Meta.

Appendix: checklist konsoli dostawcy

Utwórz web OAuth client, zarejestruj dokładny HTTPS callback dla każdego środowiska, opublikuj tylko potrzebne scopes, potem przetestuj anulowanie, odmowę zgody, istniejące konto hasłowe i brak e-maila. Facebook Graph API jest wycofywane według harmonogramu: przypnij wspieraną wersję w configu i planuj upgrade z changelogu Meta.

Kiedy tego NIE używać

Nie rób z providera społecznościowego jedynej drogi odzyskania konta firmowego. Nie auto-linkuj niezweryfikowanego e-maila. Dla enterprise SSO użyj OIDC/SAML z kontrolą domeny i lifecycle, nie consumer OAuth jako tożsamości pracownika.

Powiązane artykuły

Wsparcie istniejącego systemu

Potrzebujesz pomocy z działającą aplikacją?

Pomagam firmom rozwijać działające systemy, porządkować wdrożenia i dodawać nowe funkcje bez dokładania chaosu do projektu.

Komentarze (0)
Zaloguj się, aby dodać komentarz

Musisz być zalogowany, aby dodać komentarz.

Zaloguj się

Potrzebujesz kogoś, kto weźmie odpowiedzialność za kolejny krok?

Porozmawiajmy o Twoim projekcie i określmy zakres, który ma sens dla Twoich celów.