Logowanie i konta w aplikacji dla firmy — Google, e-mail z hasłem czy link jednorazowy?

Warstwy logowania — z czego składa się wejście do aplikacji?

Z sześciu elementów, nie z jednego ekranu: rejestracja, konto Google, hasło z resetem, link jednorazowy, sesja z odświeżaniem i role. Pierwsze cztery użytkownik widzi. Dwa ostatnie rozstrzygają, co zobaczy po wejściu — i to one bywają zrobione po łebkach.

Ta warstwa jest wbudowana w bazę, w której i tak trzymamy dane: jeden Postgres z politykami dostępu na poziomie wierszy i logowaniem użytkowników. To trzecia z czterech warstw aplikacji dla firmy, a nie osobny system obok niej.

Element, który zaskakuje najczęściej, to poczta. Wbudowana usługa pocztowa dostawcy wysyła 2 wiadomości na godzinę, a dokumentacja opisuje ją wprost jako nieprzeznaczoną do produkcji (Supabase, odczyt 31 sierpnia 2026). Potwierdzenie rejestracji, reset hasła i link jednorazowy idą tym samym kanałem.

Po podpięciu własnego nadawcy dostawca ustawia na start 30 wiadomości na godzinę i dopiero tę wartość podnosi się w ustawieniach (dokumentacja, odczyt 31 sierpnia 2026). To liczba, o którą warto zapytać przed zaproszeniem pierwszej setki kont: jedna wysyłka zaproszeń albo się w niej mieści, albo nie.

Decyzja: logowanie od dostawcy bazy, dwie drogi na start

Logowanie bierzemy stamtąd, skąd bierzemy bazę. Powód nie jest wygodą programisty. Identyfikator zalogowanej osoby musi być tą samą wartością, którą sprawdza polityka dostępu do wiersza — inaczej powstaje druga lista ludzi i tabela sklejająca ją z pierwszą.

Ta druga lista jest miejscem, w którym awarie robią się drogie. Ktoś zmienia adres w jednym systemie i nie zmienia w drugim. Konto skasowane w jednym miejscu zostaje w drugim. Każdy taki rozjazd kończy się ręcznym grzebaniem w danych, zwykle pod telefon klienta.

Alternatywy są dwie. Własny mechanizm logowania: trzeba w nim napisać reset hasła, blokady po nieudanych próbach, drugi składnik i unieważnianie sesji, a potem to utrzymywać. Osobny dostawca tożsamości jako trzecia usługa: sensowny, gdy firma ma już jedno logowanie do kilku systemów; przy jednej aplikacji dokłada tylko sklejanie.

Drogi dla użytkownika ustawiamy dwie, bo jedna zawsze kogoś odcina. Konto Google działa dla firm pracujących na Gmailu i zdejmuje z aplikacji cały temat haseł. E-mail z hasłem jest dla reszty, a reszty jest sporo: poczta na własnej domenie nie musi stać na Google.

Trzecia droga, link jednorazowy, jest dla tych, którzy logują się rzadko: raz na kwartał po raport, raz w roku po dokument. Oni i tak zapomną hasła, więc reset stałby się ich normalną drogą wejścia. Lepiej dać ją wprost, z ważnością godziny i jednym użyciem.

Co zmienia skala: 10, 1 000 i 10 000 kont?

Trzy rzeczy, w kolejności, która zaskakuje: najpierw ekran zgody Google, potem poczta, a rachunek za samo logowanie na końcu albo wcale. Limit aktywnych użytkowników w darmowym planie bazy to 50 000 miesięcznie (cennik Supabase, odczyt 31 sierpnia 2026) — nie on wypycha aplikację z planu.

Przy dziesięciu kontach pilotażowych rozstrzyga stan projektu w Google. Dopóki jest ustawiony na „Testing”, korzysta z niego najwyżej 100 użytkowników testowych, a ich zgoda wygasa po siedmiu dniach od udzielenia (dokumentacja Google Cloud, odczyt 31 sierpnia 2026). Publikacja projektu zdejmuje oba ograniczenia.

Samo logowanie nie wymaga weryfikacji aplikacji, dopóki prosi wyłącznie o zakresy niewrażliwe, czyli imię i adres e-mail (dokumentacja Google Cloud, odczyt 31 sierpnia 2026). Weryfikacja marki służy do czego innego: żeby na ekranie zgody stanęła nazwa i logo firmy, a nie surowy adres.

Przy tysiącu kont kończy się poczta i to jest pierwszy prawdziwy próg. Potwierdzenie rejestracji, reset hasła i link jednorazowy to trzy wysyłki do jednej osoby w ciągu jednego dnia. Wbudowana usługa daje 2 wiadomości na godzinę, własny nadawca startuje z 30 (dokumentacja, odczyt 31 sierpnia 2026).

Przy dziesięciu tysiącach kont zaczyna się rachunek, ale nie za logowanie. Plan Pro kosztuje od 25 USD miesięcznie i zawiera 100 000 aktywnych użytkowników, powyżej 0,00325 USD za użytkownika (cennik, odczyt 31 sierpnia 2026). Plan płatny odblokowuje za to dwa ustawienia, które przy tej skali są potrzebne.

Pierwsze to ograniczenia sesji: maksymalny czas jej życia i wylogowanie po bezczynności, dostępne od planu Pro. Drugie to blokowanie haseł znanych z wycieków, też od planu Pro (dokumentacja, odczyt 31 sierpnia 2026). Oba dotyczą kont pracowników, nie klientów — i oba włącza się raz.

Gdzie logowanie się wykłada — cztery pułapki z praktyki

• Błąd 500 z pustym komunikatem. Klient logowania potrafi zwrócić kod 500 bez treści. Awaria wygląda wtedy jak „coś nie działa” i nie da się jej odróżnić od literówki w konfiguracji.

  Reguła: logujemy pełną odpowiedź serwera, nie sam kod. Bez tego pierwsze pytanie po zgłoszeniu brzmi „a co dokładnie odpowiedział serwer”, i nie ma na nie odpowiedzi.

• Identyfikator w adresie to nie hasło. Link „bez logowania” do faktury albo raportu, w którym da się podmienić numer, otwiera cudze dane każdemu, kto ten numer zgadnie.

  Reguła: takie linki dostają token z terminem ważności i zakresem. Link jednorazowy z logowania jest tym samym wzorcem zrobionym porządnie: ważny godzinę, do jednego użycia.

• Zalogowany to nie administrator. Uprawnienie administratora sprawdzamy po identyfikatorze użytkownika w osobnej tabeli ról, nigdy po samym fakcie zalogowania.

  Co z tego wynika dla polityk dostępu do wierszy, rozpisuje osobny tekst: zasady bezpieczeństwa od pierwszego dnia.

• Wylogowanie nie działa natychmiast. Dokumentacja mówi wprost: tokeny dostępu unieważnionych sesji pozostają ważne do końca swojego czasu ważności (Supabase, odczyt 31 sierpnia 2026).

  Przy domyślnej godzinie znaczy to, że przycisk „wyloguj wszystkie urządzenia” działa z opóźnieniem. Reguła: przy kontach sięgających po cudze dane skracamy ten czas i sprawdzamy uprawnienie po stronie serwera.

Po czym poznać, że logowanie jest ustawione dobrze?

Po czterech odpowiedziach, których nie trzeba szukać w kodzie. Każde „sprawdzimy” znaczy, że ta warstwa nie jest gotowa do startu.

• Czy wiadomości z logowania wychodzą z domeny firmy, czy z wbudowanej usługi dostawcy z limitem 2 na godzinę?
• Ile trwa ważność linku jednorazowego i czy da się go użyć drugi raz?
• Po czym aplikacja poznaje administratora: po tabeli ról czy po tym, że ktoś jest zalogowany?
• Co dzieje się po kliknięciu „wyloguj na wszystkich urządzeniach” i po jakim czasie stary token przestaje otwierać dane?

Ostatnie pytanie jest najlepsze, bo odpowiedź „natychmiast” bez wskazania ustawienia znaczy, że nikt tego nie sprawdzał. Konta, hasła i ekran zgody poprawia się w jeden dzień. Sesje i uprawnienia trzeba przemyśleć raz, na początku — potem zmienia się je razem z danymi, które już istnieją.