OAuth wyjaśniony dla zespołów, które muszą go wdrożyć

Dokumentacja OAuth jest pisana dla tych, którzy implementują dostawców. Prawie każdy, kto ją czyta, chce w rzeczywistości dodać przycisk „Kontynuuj z Google”, a przepaść między tymi dwiema grupami to powód, dla którego temat wydaje się trudniejszy, niż jest.

Co się naprawdę dzieje

Wysyłasz użytkownika do Google z informacją, kim jesteś i dokąd ma wrócić. Loguje się na stronie Google — Twoja aplikacja nigdy nie widzi hasła. Google odsyła go z krótkotrwałym kodem. Twój serwer wymienia ten kod, kanałem zwrotnym, na token potwierdzający, kim jest użytkownik. To cała struktura.

Gdzie to idzie źle

• Wymiana kodu w przeglądarce, która ujawnia client secret.
• Pominięcie parametru state, który właśnie powstrzymuje fałszowanie żądań między serwisami w callbacku.
• Ufanie deklaracji e-mail bez sprawdzenia, czy jest zweryfikowana — niezweryfikowany e-mail to przejęcie konta czekające na wykorzystanie.
• Założenie, że identyfikator użytkownika u dostawcy to adres e-mail. Nie jest, a ludzie zmieniają e-maile.
• Zapomnienie o przypadku łączenia kont: ta sama osoba, drugi dostawca, dwa konta.

“Niebezpieczna część OAuth to nie protokół. To pięć drobnych decyzji, o których poradnik nie wspomniał.”

Każde z tych zagadnień jest za Ciebie obsługiwane, gdy integracja z dostawcą jest konfiguracją, a nie kodem. Logowanie przez Google jest dostępne w każdym planie Alt Auth, również w darmowym, a Apple, Facebook i Microsoft są w wyższych planach.