Po przejściu tego przewodnika użytkownicy logują się do aplikacji zatwierdzeniem z telefonu — wpisują nazwę użytkownika albo skanują kod QR, po czym potwierdzają w aplikacji Notakey. Na stronie logowania nie ma pola na hasło. Hasło wciąż istnieje, ale ma dokładnie jedno obowiązkowe zadanie: jest wymagane raz, przy rejestracji urządzenia, żeby wygenerować klucz użytkownika. Wszystko, co dzieje się później, to decyzja administratora dotycząca polityki — i ten przewodnik pokazuje dokładnie, gdzie każda z tych polityk się ustawia.
Każda usługa Notakey — te same, których już Państwo używają do 2FA w VPN, Windows czy Wi-Fi — może działać również jako dostawca OpenID Connect. Nie trzeba do tego osobnego produktu: wystarczy włączyć OIDC dla usługi w Dashboardzie, zarejestrować aplikację jako klienta i wskazać jej punkty końcowe udostępnione przez Notakey. Żadnych certyfikatów SAML, żadnego osobnego serwera dostawcy tożsamości do utrzymania.
your app ──OIDC──▶ Notakey service (OIDC provider)
│
├──▶ user repository: onboarded devices in this service
└──▶ push ──▶ user's phone: read, approve(Klasyczne aplikacje korporacyjne obsługujące wyłącznie SAML — Google Workspace, AWS — wymagają zamiast tego osobnego dostawcy tożsamości SAML od Notakey; gdzie go znaleźć, pokazuje ostatnia sekcja.)
Jak naprawdę działa tu hasło
To temat wymagający precyzji, bo słowo „bez hasła“ bywa nadużywane:
- Jedyne obowiązkowe hasło pojawia się przy onboardingu. Ustawione w Dashboardzie albo pobrane z Active Directory, jest sprawdzane raz — gdy użytkownik rejestruje urządzenie i w bezpiecznym sprzęcie telefonu generowany jest jego klucz.
- Codzienne logowanie obywa się bez niego. Użytkownik wpisuje nazwę użytkownika albo skanuje kod QR — stronę logowania można ograniczyć do samego skanowania, bez żadnego pola do wypełnienia. Weryfikacją tożsamości jest podpisane zatwierdzenie w aplikacji.
- Wszystko poza tym to ustawienie, nie sztywna reguła. Jedna aplikacja może wymagać dodatkowego potwierdzenia w aplikacji, druga hasła, trzecia jednego i drugiego. Hasło można też pytać cyklicznie, żeby po prostu nie wyszło z pamięci użytkownika. Wszystko to konfiguruje się na jednym ekranie — pokazanym w kroku 5.
Krok 1 — Wybierz usługę
Skorzystaj z istniejącej usługi Notakey, jeśli jej użytkownicy pokrywają się już z aplikacją, którą Państwo podłączają, albo utwórz nową (Services → Manage → New), jeśli ta aplikacja ma mieć własną, niezależną politykę haseł. Polityka z kroku 5 obowiązuje dla całej usługi, a nie osobno dla każdego klienta — to jest czynnik decydujący.
Krok 2 — Włącz OpenID Connect
Otwórz usługę, przejdź do OpenID Connect configuration → Configure i zaznacz Enabled. Resztę na razie zostaw bez zmian — opcje Require password i Require mfa ustawimy świadomie w kroku 5, a nie przypadkiem już tutaj. Zapisz.
Krok 3 — Skopiuj punkty końcowe
Wróć do OpenID Connect configuration i kliknij Show. Notakey wygenerował już dokument discovery, a pod nim poszczególne punkty końcowe:
https://<your-dashboard-host>/oidc/services/<access-id>/.well-known/openid-configurationWiększości oprogramowania obsługującego OIDC wystarczy ten jeden adres URL —
wklej go w pole „auto discovery“ albo „issuer“, a aplikacja sama pobierze
punkty końcowe authorization, token, userinfo i JWKS. <access-id> to ten
sam identyfikator, który widać na stronie samej usługi.
Krok 4 — Zarejestruj aplikację jako klienta
W ramach usługi wejdź w OpenID Connect configuration → Clients → New client. Notakey wygeneruje za Państwa Client ID i losowy Secret.
Zanim zapiszesz, dwie rzeczy warte uwagi: pole Secret jest zamaskowane i po opuszczeniu strony Notakey już go nie pokaże, więc skopiuj je od razu — albo zaznacz pole i wklej własny sekret, co działa równie dobrze, a łatwiej go później odnaleźć. Pole Redirect URIs musi zaś zgadzać się co do znaku z adresem URL, który aplikacja zwraca podczas logowania — brakujący ukośnik na końcu wystarczy, żeby wszystko przestało działać (patrz pułapka niżej).
Uzupełnij:
- Description — cokolwiek, co pomoże potem rozpoznać ten wpis.
- Secret — skopiowany wygenerowany sekret albo własny, wpisany na jego miejsce.
- Redirect URIs — adres URL callbacku OAuth aplikacji. Jeśli aplikacja jest dostępna pod kilkoma adresami, oddziel je przecinkami.
- Logout URI — adres, na który przekierować przeglądarkę po wylogowaniu. Opcjonalne.
Gdy zarejestrujesz kilka aplikacji, lista klientów usługi wygląda tak:
Krok 5 — Wskaż aplikacji Notakey
Dokładne kroki zależą od aplikacji, ale schemat jest zawsze ten sam: adres issuer albo discovery, client ID, client secret. Dwa przykłady z prawdziwych narzędzi samodzielnie hostowanych:
Gitea ma na to gotową komendę CLI — bez formularza w przeglądarce, bez restartu:
gitea admin auth add-oauth \
--name notakey \
--provider openidConnect \
--key <client-id> \
--secret <client-secret> \
--auto-discover-url https://<dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration \
--scopes openid --scopes profile --scopes emailNa stronie logowania Gitei od razu pojawia się przycisk „Sign in with notakey“, obok istniejącego formularza z hasłem — nic nie znika.
Proxmox VE traktuje to jako osobny realm uwierzytelniania, dodawany do tych, które już istnieją:
pveum realm add notakey --type openid \
--issuer-url https://<dashboard-host>/oidc/services/<access-id> \
--client-id <client-id> \
--client-key <client-secret> \
--username-claim sub \
--scopes "openid email profile" \
--autocreate 1--issuer-url to tu adres discovery bez końcówki
/.well-known/openid-configuration — Proxmox dokleja ją sam. --autocreate 1
przy pierwszym udanym logowaniu tworzy odpowiadającego użytkownika
Proxmoksa, ale bez żadnych uprawnień, dopóki nie nada się ich wprost —
dostępu nie rozda przez przypadek.
Krok 6 — Ustaw politykę haseł
To właśnie ta część „decyzji administratora“ w praktyce, znów na ekranie OpenID Connect configuration → Configure:
- Require password odznaczone, Require mfa zaznaczone: przepływ bez hasła opisany na początku przewodnika. Logowanie to nazwa użytkownika (albo QR) plus zatwierdzenie z telefonu, nic więcej.
- Require password zaznaczone, Password cache pozostawione na
0: hasło przy każdym logowaniu, dodatkowo do zatwierdzenia — klasyczne dwa składniki. - Require password zaznaczone, a Password cache ustawione w
sekundach (np.
2592000dla 30 dni): na co dzień bez hasła, z ponownym pytaniem o nie dopiero po upływie tego okresu — wyłącznie po to, żeby użytkownik go nie zapomniał. Mfa cache działa tak samo dla kroku zatwierdzenia, jeśli kiedyś zechcą Państwo cache’ować i jego.
Ponieważ to ustawienie obowiązuje dla całej usługi, aplikacja wymagająca innej polityki niż jej sąsiedzi powinna dostać własną usługę — wracamy do wyboru z kroku 1.
Gdy coś nie działa
- Błąd redirect_uri mismatch niemal zawsze oznacza ukośnik na końcu:
jedne aplikacje wysyłają
https://app.example.com, innehttps://app.example.com/, a Notakey porównuje ciąg znak po znaku. Sprawdź w logach nginksa albo samej aplikacji dosłowną wartośćredirect_uri=, którą wysłała, i zarejestruj dokładnie taką. - Jeśli adres discovery zwraca 404, sprawdź jeszcze raz, czy Enabled faktycznie zostało zapisane w kroku 2 — ekran konfiguracji, który wygląda dobrze, ale nigdy nie został wysłany, to najczęstsza wpadka.
- Log Authentication activities w ramach usługi pokazuje każdą próbę, która dotarła do Notakey. Jeśli jakaś próba się tam nie pojawia, aplikacja w ogóle nie dotarła do punktu authorization — najpierw sprawdź client ID i adres discovery.
Czego ten przewodnik świadomie nie obejmuje
Klasyczne integracje SAML 2.0 dla aplikacji mówiących wyłącznie tym protokołem — Google Workspace, AWS i podobne — idą przez osobnego dostawcę tożsamości SAML od Notakey, nie przez ścieżkę OIDC opisaną powyżej. Poza zakresem tego przewodnika zostają też LDAP/Active Directory jako repozytorium użytkowników, konfiguracje wielodostępowe (multi-tenant) i własny branding. Wszystko to znajduje się w dokumentacji CLI i API wraz z pełnymi tabelami parametrów — ten przewodnik to najkrótsza droga od zera do działającego logowania bez hasła.
Zobacz to, zanim zbudujesz
Najszybszym sposobem, by ocenić sam przepływ logowania, jest wypróbowanie zatwierdzenia na własnym telefonie: wypróbuj demo na żywo i podpisz żądanie w około dwie minuty, albo poproś o prezentację, a odwzorujemy Państwa aplikacje i politykę haseł w pilotaż na Państwa własnej infrastrukturze.