Jak dodać logowanie do aplikacji: hasła, magiczne linki, Google i role

Aby dodać logowanie do aplikacji, wybierz metodę — e-mail i hasło, magiczne linki (jednorazowy link logowania wysyłany e-mailem) albo „Zaloguj przez Google” — i wdroż ją za pomocą sprawdzonej biblioteki uwierzytelniania lub hostowanego dostawcy, zamiast pisać wszystko od zera. Następnie określ, co może robić każdy typ użytkownika (role), i egzekwuj to po stronie serwera przy każdej stronie i każdym żądaniu API. Sesje powinny używać bezpiecznych cookies, wygasać i kończyć się poprawnie przy wylogowaniu.

Ten przewodnik omawia każdy wybór i szczegóły, które odróżniają działające logowanie od bezpiecznego. Pojęcia stojące za tym opisuje czym jest uwierzytelnianie.

Najpierw zdecyduj: czy w ogóle potrzebujesz logowania?

Logowanie dodaje tarcie i odpowiedzialność. Potrzebujesz go, gdy:

• Użytkownicy mają prywatne dane (swoje rezerwacje, dokumenty, faktury)
• Użytkownicy mogą zmieniać rzeczy, które zobaczą inni
• Pobierasz opłaty za dostęp
• Różne osoby potrzebują różnych uprawnień (właściciel, pracownik, klient)

Możesz nie potrzebować go w serwisie marketingowym, publicznym katalogu czy formularzu, który po prostu wysyła ci e-mail. Lista oczekujących nie wymaga kont; wystarczy pole e-mail.

Cztery popularne metody logowania

Wiele aplikacji łączy dwie metody: Zaloguj przez Google plus magiczne linki e-mail to popularne połączenie, które obejmuje większość osób bez przechowywania haseł.

E-mail i hasło

Jeśli oferujesz hasła, to obowiązkowe zasady:

• Haszuj hasła wolnym algorytmem przeznaczonym do haseł. Wytyczne OWASP dotyczące przechowywania haseł zalecają Argon2id, a jako alternatywy scrypt, bcrypt lub PBKDF2. Nigdy nie przechowuj haseł jawnym tekstem ani zwykłym szybkim haszem.
• Resetowanie hasła używa losowego, jednorazowego linku, który wygasa, wysyłanego na zweryfikowany e-mail.
• Nie ujawniaj, które e-maile mają konta. „Jeśli ten e-mail jest zarejestrowany, wysłaliśmy link do resetu” jest lepsze niż „Nie znaleziono konta”.
• Ogranicz liczbę prób logowania i resetu, aby spowolnić zgadywanie haseł.
• Pozwól na długie hasła i menedżery haseł; zrezygnuj z reguł wymuszających dziwne kombinacje znaków.

Magiczne linki i jednorazowe kody

Magiczny link to link do logowania wysyłany użytkownikowi e-mailem. Kliknięcie go loguje użytkownika. Jednorazowy kod to ta sama idea, tylko wpisywana zamiast klikanej.

• Linki i kody szybko wygasają i działają tylko raz.
• Link powinien zalogować użytkownika na urządzeniu, na którym kliknął, a token nie może pozostawać w logach ani w narzędziach analitycznych.
• Potrzebujesz niezawodnego wysyłania e-maili — zobacz jak wysyłać e-maile z aplikacji. Testuj w Gmailu i Outlooku oraz sprawdzaj foldery spam.

Zaloguj przez Google (i inni dostawcy OAuth)

„Zaloguj przez Google” korzysta z OAuth i OpenID Connect: Google potwierdza, kim jest użytkownik, i przekazuje twojej aplikacji jego e-mail i imię. Konfiguracja, według stanu na wrzesień 2026, odbywa się w sekcji Google Auth Platform w Google Cloud Console:

1. Utwórz lub wybierz projekt i uzupełnij stronę Branding — co użytkownicy widzą na ekranie zgody (nazwa aplikacji, e-mail wsparcia, logo).
2. Na stronie Clients utwórz klienta typu „Web application”.
3. Dodaj authorized JavaScript origins i redirect URIs — dokładne adresy, pod którymi działa twoja aplikacja i na które Google odsyła użytkownika po zalogowaniu.
4. Zapisz identyfikator klienta i sekret klienta w sekretach aplikacji.

Rzeczy, które często idą źle, według dokumentacji OAuth Google:

• redirect_uri_mismatch: adres przekierowania musi pasować dokładnie, łącznie z http vs https, wielkością liter i ukośnikiem na końcu. Dodaj jeden dla adresu podglądu i jeden dla twojej domeny produkcyjnej.
• Wymagany HTTPS: adresy przekierowania muszą używać HTTPS, z wyjątkiem localhost w czasie rozwoju.
• Parametr state powinien być sprawdzany przy powrocie, aby chronić przed fałszowaniem żądań między stronami (CSRF). Dobre biblioteki robią to za ciebie.

Jeśli prosisz tylko o podstawowe informacje do logowania (imię, e-mail, profil), Google twierdzi, że weryfikacja aplikacji nie jest obowiązkowa. Prośba o dostęp do Gmaila, Dysku czy Kalendarza użytkowników to co innego i wymaga weryfikacji.

Zbudować samemu czy użyć dostawcy?

Oba pierwsze podejścia są rozsądne. Hostowani dostawcy obsługują więcej za ciebie, ale dodają zależność i czasem kosztują za aktywnego użytkownika; aktualne ceny sprawdź na ich stronach. Biblioteki trzymają wszystko w twojej bazie, ale zostawiają więcej do poprawnej konfiguracji. Cokolwiek wybierzesz, poproś AI o użycie tego rozwiązania, zamiast ręcznie pisać logikę haseł czy sesji.

Role i uprawnienia

Logowanie mówi ci, kim ktoś jest. Uprawnienia decydują, co może zrobić. Na początku trzymaj to prosto:

Zasady ważniejsze niż nazwy ról:

• Sprawdzaj na serwerze, za każdym razem. Ukrycie przycisku na stronie nie powstrzyma nikogo przed bezpośrednim wywołaniem API.
• Zakres według właściciela. Członek pobierający „rezerwację 123” powinien ją dostać tylko wtedy, gdy jest jego.
• Użytkownicy nie mogą awansować sami siebie. Ignoruj pola ról przesyłane z przeglądarki przy aktualizacji profilu.
• Domyślnie brak dostępu. Nowe trasy powinny wymagać logowania, chyba że zdecydujesz inaczej.

Przetestuj to dwoma kontami: zaloguj się jako jeden, zapisz ID rekordu, zaloguj się jako drugi i spróbuj go otworzyć. Nasza lista kontrolna bezpieczeństwa zawiera pełny test.

Bezpieczeństwo sesji

Po zalogowaniu aplikacja zapamiętuje użytkownika dzięki sesji — zwykle cookie. Wytyczne OWASP dotyczące zarządzania sesją zalecają:

• Cookies sesji ustawione z Secure (tylko HTTPS), HttpOnly (nieczytelne dla skryptów strony) i SameSite
• Nowy identyfikator sesji wydawany przy logowaniu oraz ponownie przy zmianie uprawnień
• Limit bezczynności i maksymalny czas życia sesji, egzekwowane na serwerze
• Wylogowanie, które kończy sesję po stronie serwera, a nie tylko usuwa cookie
• Sesje unieważniane po zmianie hasła przez użytkownika

Przechowywanie tokenów logowania w local storage przeglądarki jest częste w poradnikach, ale udostępnia je każdemu skryptowi działającemu na stronie; bezpieczne cookies są zwykle lepszym domyślnym wyborem w aplikacjach webowych.

Prompt, który obejmuje podstawy

Dodaj konta użytkowników do tej aplikacji. Użytkownicy mogą się rejestrować i logować przez e-mail i hasło albo przez Google. Użyj [biblioteki lub dostawcy] zamiast własnego kodu uwierzytelniania. Haszuj hasła przez Argon2id lub bcrypt. Dodaj reset hasła e-mailem z jednorazowym linkiem wygasającym po godzinie. Trzymaj sesje w bezpiecznych cookies HttpOnly. Chroń /dashboard i każdą trasę /api, tak aby tylko zalogowani użytkownicy mogli ich używać, i upewnij się, że użytkownicy widzą tylko swoje projekty. Dodaj rolę „admin”, która widzi wszystkich użytkowników; tylko administratorzy mogą wejść na /admin, sprawdzane na serwerze.

Potem przetestuj: zarejestruj się, wyloguj, zaloguj, zresetuj hasło, spróbuj wejść na prywatny URL będąc wylogowanym i spróbuj otworzyć rekord innego użytkownika.

Typowe błędy w logowaniu budowanym przez AI

• Ochrona tylko na stronie. Strona przekierowuje wylogowanych użytkowników, ale API zwraca dane każdemu.
• Sekrety w przeglądarce. Sekrety klienta OAuth i klucze administracyjne dostawcy uwierzytelniania należą na serwer.
• Pomylone adresy podglądu i produkcyjne. Redirect URI Google albo link do resetu hasła wskazuje na podgląd, więc logowanie psuje się po publikacji.
• Brak weryfikacji e-maila. Każdy może się zarejestrować jako anyone@firma.pl. Weryfikuj e-mail, zanim przyznasz cokolwiek powiązanego z tym adresem.
• Testowanie tylko ścieżki szczęśliwej. Spróbuj złych haseł, wygasłych linków i drugiego konta.

Dodawanie logowania w Mythex

W Mythex logowanie dla użytkowników twojej aplikacji dodajesz do samej aplikacji — jest ono oddzielne od twojego własnego konta Mythex. Mythex nie oferuje wbudowanego produktu uwierzytelniania, więc przynosisz bibliotekę lub dostawcę uwierzytelniania oraz ich klucze:

1. Wybierz podejście — na przykład e-mail i hasło przechowywane we własnej bazie albo SDK hostowanego dostawcy.
2. Jeśli przechowujesz użytkowników samodzielnie, aplikacja potrzebuje bazy danych; poproś o nią w czacie lub użyj /database.
3. Umieść klucze dostawcy w sekretach projektu (/secrets lub ustawienia projektu).
4. Użyj promptu jak powyżej i przetestuj w Preview. Dla logowania przez Google dodaj redirect URI zarówno dla podglądu, jak i dla opublikowanego adresu.

Zobacz Add login to your app w dokumentacji. Jeśli budujesz płatny produkt, jak zbudować MVP SaaS omawia konta i rozliczenia razem.

Pytania