Profile uwierzytelniania – gdy Approve ma robić coś więcej niż logować

Każde uwierzytelnienie w Notakey kończy się tak samo: użytkownik czyta, co potwierdza, i naciska Approve albo Deny: podpisane, możliwe do audytu tak lub nie. Zwykle ta odpowiedź odblokowuje logowanie. Urządzeniu jest jednak obojętne, jak brzmiało pytanie: profil uwierzytelniania pozwala podłączyć do tej odpowiedzi serwerowe callbacki, dzięki czemu Approve (lub Deny) może uruchomić cokolwiek, co ma API HTTP: kontroler drzwi, politykę sieciową, system zgłoszeń, inteligentny przekaźnik.

QR scan or API call ──▶ auth request ──▶ push/app ──▶ user taps Approve
     (from a profile)                                        │
                                              callbacks fire in the background:
                                              ├─▶ https://door.local/open?…
                                              ├─▶ https://nac/api/policy…
                                              └─▶ anything else you add

Elementy składowe, wszystkie prosto z produktu:

Profil definiuje żądanie, które widzi użytkownik (tytuł, opis, okres ważności), z podstawianiem {variable} ({username}, {user_email}, {state} i podobne) w dowolnym polu.
Do każdego profilu podłączasz callbacki do zdarzeń: Create (żądanie utworzone), Approve, Deny, Response (dowolna z odpowiedzi), Error lub Any. Liczba callbacków na profil jest nieograniczona, a wykonują się one w tle, więc powolne API innego dostawcy nigdy nie blokuje samego uwierzytelniania.
Każdy wywoływany adres URL można zabezpieczyć danymi logowania klienta OAuth 2.0 lub uwierzytelnianiem nagłówkowym (wspólny token), więc nie musisz wystawiać nieuwierzytelnionego webhooka.

Profile tworzysz w panelu, w sekcji Authentication profiles swojej usługi; żądania mogą się następnie odwoływać do profilu albo z poziomu API, albo (i to właśnie czyni zastosowania w świecie fizycznym praktycznymi) z kodu QR, całkowicie bez powiadomienia push.

Wypróbuj to od razu: demo bank loguje Cię właśnie tak

Nie musisz wierzyć nam na słowo, jak to działa w praktyce: logowanie do demo banku jest tym mechanizmem. Strona logowania pokazuje kod QR. Na samej stronie nie wpisujesz niczego. Otwórz Notakey Authenticator, naciśnij przycisk skanowania i skieruj aparat na ekran:

Zeskanowanie kodu tworzy żądanie uwierzytelnienia bezpośrednio na Twoim telefonie. To działanie deeplinku a=a z następnej sekcji. Widzisz dokładnie, co potwierdzasz, i jedno naciśnięcie Approve:

…i karta przeglądarki, z której skanowałeś, jest zalogowana. Najciekawsza jest niewidoczna połowa: Twoje potwierdzenie wyzwala callback do backendu banku z parametrem state żądania, backend dopasowuje go do oczekującej strony i sesja się otwiera. Pole nazwy użytkownika, pole hasła, link „nie pamiętam hasła” – nic z tego nie istnieje, bo nic z tego nie jest potrzebne. To ten sam wzorzec, który reszta tego przewodnika kieruje na inne cele.

Przykład praktyczny: drzwi, które pytają Twój telefon

Drzwi do centrum danych, a obok zalaminowany kod QR. Zeskanowanie go za pomocą Notakey Authenticator tworzy żądanie uwierzytelnienia od razu na miejscu. Akcja deeplinku a=a jest udokumentowana jako „zażądaj uwierzytelnienia bez powiadomienia push”, więc działa to, mimo że nikt niczego nie wysłał na telefon:

notakey://qr?a=a&u=ntk.example.com&k=<service-id>&p=<profile-id>

Zakoduj ten URI w kodzie QR (k to identyfikator usługi, p – identyfikator profilu, oba widoczne w panelu) i wydrukuj go. Profil, który za tym stoi:

Tytuł/opis: „Otwórz drzwi DC — {username}, potwierdź biometrią”. Ustaw krótką ważność, np. 60 sekund; nikt nie skanuje kodu przy drzwiach i nie zastanawia się nad nim pięć minut.
Callback przy Approve: API kontrolera drzwi, https://door-controller.internal/open?door=dc-1&user={username}, zabezpieczone tokenem w nagłówku. Approve → wywołanie HTTP → zamek się otwiera.
Callback przy Deny (opcjonalny, ale warto): żądanie, które zostało utworzone, ale odrzucone, oznacza, że ktoś stał przy Twoich drzwiach, a właściciel telefonu powiedział nie. Podłącz to do swojego systemu alarmowania. Zmienne {response_ip} i {username} opowiadają, co się stało.
Callback przy Create (opcjonalny): wpis w dzienniku audytu w chwili, gdy ktokolwiek skanuje, zanim odpowie.

Dla użytkownika to ten sam przebieg co w demo banku, tylko skierowany na zamek zamiast na płatność: zeskanuj, przeczytaj, co potwierdzasz, naciśnij – i rzecz się dzieje. Żadnych kart zbliżeniowych do sklonowania, żadnego PIN-u do drzwi współdzielonego przez cały zespół, a każde otwarcie to podpisane zdarzenie przypisane do konkretnej osoby.

Przykład praktyczny: logowanie do VPN, które konfiguruje sieć

Callbacki łączą się z konfiguracjami RADIUS z naszego przewodnika po VPN 2FA. Jeden wzorzec z rzeczywistego wdrożenia, z kontrolerem Aruba: VPN uwierzytelnia użytkownika przez RADIUS za pośrednictwem auth-proxy jak zwykle, a następnie callback nakazuje kontrolerowi sieci aktywować właściwy profil sieciowy dla tego użytkownika. Logowanie i autoryzacja sieciowa stają się jednym potwierdzeniem zamiast dwóch systemów, które, miejmy nadzieję, są ze sobą zgodne.

To w treści callbacku zmienne profilu pokazują swoją wartość: {username}, {user_guid} (identyfikator GUID z Active Directory, przydatny jako stabilny klucz po stronie kontrolera) oraz {state} są podstawiane osobno dla każdego żądania, więc jeden profil obsługuje wszystkich użytkowników.

Od strony API

Wszystko, co potrafi uruchomić kod QR, potrafi też Twój backend. API żądań uwierzytelnienia przyjmuje parametr profile (żądanie przejmuje wtedy tytuł, tekst i ważność z profilu) oraz custom_vars, hasz JSON z Twoimi własnymi parami klucz–wartość, które przepływają aż do pól i callbacków profilu. System rezerwacji może na przykład przekazać {"room": "B12", "slot": "14:00"}, pokazać dokładnie to na telefonie, a następnie podać dalej do callbacku, który o właściwej porze otwiera właściwe pomieszczenie.

Dwa szczegóły, które warto poznać, zanim zaczniesz budować:

Deny i Error to też zdarzenia. Najbardziej przydatne callbacki w środowisku produkcyjnym często nie leżą na ścieżce pozytywnej: powiadom kogoś przy Deny, zapisz Error z {error} / {error_message}, gdy docelowe API przestało odpowiadać.
Z perspektywy użytkownika callbacki działają w trybie „uruchom i zapomnij”. Wykonują się w tle; wiele równoległych callbacków na mocno obciążonym urządzeniu może ustawić się w kolejce. Zaprojektuj stronę odbierającą jako idempotentną; {uuid} żądania jest Twoim kluczem do deduplikacji.

Gdzie to pasuje

Uwierzytelnianie było najtrudniejszą częścią: podpisane, przypisane do osoby, potwierdzone biometrią tak/nie ze śladem audytu. Profile pozwalają wykorzystać ten element ponownie do wszystkiego, co go otacza: dostępu fizycznego, polityk sieciowych, zatwierdzeń w narzędziach wewnętrznych. Jeśli urządzenie obsługuje już Twoje logowania, kolejny system typu „kto to zatwierdził?”, który właśnie zamierzałeś zbudować, może dzielić od gotowości tylko jeden profil i jeden callback.

Powiązane przewodniki

Powiadomienia push z dowolnego skryptu: informacyjna połowa tego samego API
VPN 2FA z RADIUS – kompletna konfiguracja auth-proxy: przebieg RADIUS, na którym opiera się wzorzec Aruba
Wypróbuj demo bank: ten sam przebieg skanuj-sprawdź-potwierdź, skierowany na transakcję