Czym jest uwierzytelnianie? Logowanie, sesje i OAuth wyjaśnione

Uwierzytelnianie to sposób, w jaki aplikacja potwierdza, kim jest użytkownik — zwykle sprawdzając coś, co zna (hasło), coś, co ma (kod wysłany na telefon lub e-mail), albo tożsamość od zaufanej zewnętrznej usługi (na przykład „Zaloguj się przez Google”). Gdy użytkownik zostanie uwierzytelniony, aplikacja zapamiętuje go za pomocą sesji lub tokena, dzięki czemu nie musi logować się przy każdej stronie. Ustalenie, co ten rozpoznany użytkownik może robić, to osobny krok zwany autoryzacją.

Dlaczego to ma znaczenie, gdy budujesz z AI

Dodanie logowania to jedna z najczęstszych próśb kierowanych do kreatora AI i jedna z tych rzeczy, które łatwo zrobić subtelnie źle. Stronę logowania da się wygenerować prosto. Trudna jest reszta:

• Czy hasła są przechowywane bezpiecznie?
• Czy każda prywatna strona i każdy endpoint API faktycznie sprawdza, kto pyta?
• Czy zalogowany klient może zobaczyć dane innego klienta, zmieniając numer w adresie URL?
• Co się dzieje, gdy ktoś zapomni hasła?

Aplikacja może wyglądać na bezpieczną, a jednocześnie nie spełniać żadnego z tych warunków. Zrozumienie ruchomych części pozwala zadawać właściwe pytania i testować właściwe rzeczy.

Codzienna analogia

Pomyśl o zameldowaniu się w hotelu.

Na recepcji pokazujesz dowód tożsamości. To uwierzytelnianie: udowodnienie, kim jesteś. Recepcjonista wydaje ci kartę do pokoju. Ta karta to twoja sesja: przez resztę pobytu nie pokazujesz dowodu ponownie; przykładasz kartę.

Karta otwiera twój pokój, siłownię i windę na twoje piętro — ale nie pokoje innych gości ani biuro personelu. To autoryzacja: do czego twoja tożsamość ma dostęp. Jeśli zgubisz kartę, hotel może ją dezaktywować przy recepcji (unieważnienie sesji). Przy wymeldowaniu przestaje działać (wylogowanie lub wygaśnięcie).

„Zaloguj się przez Google” to tak, jakby hotel przyjął list od zaufanego partnera, potwierdzający, kim jesteś, zamiast sprawdzać twój dowód samemu.

Główne metody logowania

Jak powinno się przechowywać hasła

Bezpieczna aplikacja nigdy nie przechowuje twojego właściwego hasła. Zamiast tego przechowuje hasz: wynik jednokierunkowej funkcji, która zamienia hasło w stały ciąg znaków. Kiedy się logujesz, aplikacja haszuje to, co wpisałeś, i porównuje wynik z zapisanym haszem.

Dwa szczegóły sprawiają, że to jest bezpieczne:

• Sól — losowa wartość dodawana do każdego hasła przed haszowaniem, dzięki czemu dwie osoby z tym samym hasłem mają różne hasze, a gotowe tablice wyszukiwania są bezużyteczne.
• Wolny algorytm stworzony do haseł — taki jak Argon2, bcrypt lub scrypt. Ogólne funkcje skrótu, takie jak MD5 czy SHA-256, są samodzielnie zbyt szybkie; atakujący mogą sprawdzać miliardy prób.

Haszowanie to nie to samo co szyfrowanie. Zaszyfrowane dane można odszyfrować kluczem; hasz hasła jest zaprojektowany tak, by w ogóle nie dało się go odwrócić.

Sesje a tokeny

Po zalogowaniu aplikacja musi rozpoznawać cię przy każdym żądaniu. Są dwa popularne podejścia.

Dla ciasteczek trzy ustawienia mają znaczenie: HttpOnly (JavaScript na stronie nie może odczytać ciasteczka), Secure (wysyłane tylko przez HTTPS) i SameSite (ogranicza wysyłanie go przy żądaniach z innych stron). Przechowywanie tokenów w localStorage przeglądarki jest powszechne, ale wystawia je na każdy skrypt działający na stronie.

OAuth i „Zaloguj się przez Google”

OAuth 2.0 to standard delegowanej autoryzacji: pozwala aplikacji uzyskać ograniczony dostęp do twojego konta w innej usłudze — na przykład do odczytu twojego kalendarza Google — bez poznawania twojego hasła do Google. Zostajesz przekierowany do Google, zatwierdzasz konkretne uprawnienia (zwane zakresami, czyli scopes), a Google wydaje aplikacji token tylko na te uprawnienia.

Sam OAuth został zaprojektowany do przyznawania dostępu, a nie do stwierdzania, kim jesteś. OpenID Connect (OIDC) to warstwa nad OAuth 2.0, która dodaje tożsamość — to z niej korzysta „Zaloguj się przez Google” czy „Zaloguj się przez Apple”. Aby to skonfigurować, rejestrujesz aplikację u dostawcy i dostajesz identyfikator klienta oraz sekret klienta; sekret pozostaje na twoim serwerze.

Przykład krok po kroku: logowanie do portalu klienta

Załóżmy, że budujesz portal, w którym klienci agencji projektowej widzą swoje projekty i faktury.

• Uwierzytelnianie: klienci logują się e-mailem i linkiem magicznym, więc nie ma haseł do zarządzania. Pracownicy agencji logują się kontami Google Workspace.
• Role: każdy użytkownik ma rolę — client lub staff.
• Reguły autoryzacji:

• Gdzie to jest egzekwowane: na serwerze, przy każdym żądaniu. Serwer sprawdza zalogowanego użytkownika, a potem zwraca tylko te projekty, w których project.company_id odpowiada firmie użytkownika. Samo ukrycie przycisku „Oznacz jako opłacone” nie wystarcza — endpoint sam musi odmówić.

Wyjaśnienie najważniejszych pojęć

Częste błędy i mylne przekonania

• Sprawdzanie uprawnień tylko na stronie. Jeśli przeglądarka ukrywa przycisk, ale API nie sprawdza, każdy może wywołać API bezpośrednio.
• Ufanie identyfikatorom z adresu URL. /invoices/1042 musi sprawdzić, czy faktura 1042 należy do zalogowanego użytkownika.
• Pisanie własnej kryptografii. Używaj znanych bibliotek lub dostawców; nie pozwalaj AI wymyślać własnego schematu haszowania.
• Słabe resetowanie hasła. Linki do resetu powinny być jednorazowe, szybko wygasać i nie zdradzać, czy e-mail ma konto.
• Mylenie logowania do aplikacji z logowaniem do narzędzia. Użytkownicy twojej aplikacji są oddzieleni od twojego konta w narzędziu, w którym ją budujesz.
• Brak limitu prób logowania. Bez niego atakujący mogą w nieskończoność próbować haseł.

O co poprosić swojego kreatora AI

• „Dodaj rejestrację i logowanie przy użyciu [znanej biblioteki lub dostawcy]. Nie pisz własnego haszowania haseł.”
• „Przechowuj hasła zahaszowane przez bcrypt lub Argon2.”
• „Użyj ciasteczek sesji z flagami HttpOnly i Secure.”
• „Dodaj role: admin i member. Wypisz każdy endpoint i to, które role mogą go wywołać.”
• „Wymuś na serwerze, by użytkownicy mogli odczytywać i edytować tylko własne rekordy. Potem pokaż, jak to sprawdziłeś.”
• „Dodaj resetowanie hasła z jednorazowymi linkami, które wygasają po godzinie.”
• „Ogranicz liczbę prób logowania.”

Potem sprawdź to sam: utwórz dwa konta i spróbuj dotrzeć do danych jednego z nich, będąc zalogowanym jako drugie. Nasz przewodnik po dodawaniu logowania i lista kontrolna bezpieczeństwa wchodzą głębiej.

Uwierzytelnianie w Mythex

Mythex nie dostarcza wbudowanego produktu do uwierzytelniania użytkowników twojej aplikacji; sam wybierasz podejście — e-mail i hasło zapisane w bazie danych projektu albo SDK hostowanego dostawcy — i prosisz agenta, by je dodał. Klucze dostawców trafiają do sekretów projektu, a nie na czat. Jest to osobne od tego, jak logujesz się do samego Mythex. Dokumentacja, przepis dodawania logowania do aplikacji, zawiera gotowy prompt, który możesz dostosować, a czym jest API wyjaśnia, gdzie żyją te sprawdzenia po stronie serwera.

Pytania