Jelszó nélküli SSO a Notakey-vel: lépésről lépésre konfigurációs útmutató

Az útmutató végére a felhasználók telefonos jóváhagyással jelentkeznek be egy alkalmazásba: beírnak egy felhasználónevet, vagy beolvasnak egy QR-kódot, majd megerősítik a kérést a Notakey appban. A bejelentkezési oldalon nincs jelszó. A jelszó persze létezik, de pontosan egyetlen kötelező feladata van: egyszer, a készülék regisztrálásakor kell megadni, amikor létrejön a felhasználó kulcsa. Minden, ami ezután történik, már az Ön szabályzati döntése — ez az útmutató pontosan megmutatja, hol állítható be melyik.

Minden Notakey-szolgáltatás — akár már most is használja VPN-hez, Windowshoz vagy Wi-Fi 2FA-hoz — egyúttal OpenID Connect szolgáltatóként is működhet. Ehhez nem kell külön termék: kapcsolja be az OIDC-t a szolgáltatáson az irányítópulton, regisztrálja kliensként azt az alkalmazást, amely használni fogja, majd irányítsa az alkalmazást a Notakey által megadott végpontokra. Nincs szükség SAML-tanúsítványokra, sem külön futtatandó identity provider szerverre.

your app ──OIDC──▶ Notakey service (OIDC provider)
                        │
                        ├──▶ user repository: onboarded devices in this service
                        └──▶ push ──▶ user's phone: read, approve

(A kizárólag SAML-t beszélő vállalati alkalmazásokhoz — Google Workspace, AWS — a Notakey külön SAML identity providere kell, nem ez az út; ennek helyét az utolsó szakaszban találja meg.)

Hogyan működik itt valójában a jelszó

Érdemes pontosan fogalmazni, mert a „jelszó nélküli” kifejezést sokszor csak úgy odavetik:

Az onboarding az egyetlen kötelező jelszó. Az irányítópulton állítható be, vagy az Active Directoryból érkezik, és egyszer kerül ellenőrzésre: amikor a felhasználó regisztrálja a készülékét, és a kulcsa létrejön a telefon biztonságos hardverében.
A napi bejelentkezéshez nem kell jelszó. A felhasználó beírja a felhasználónevét, vagy beolvas egy QR-kódot — a bejelentkezési oldal akár tisztán QR-alapúra is egyszerűsíthető, ahol semmit sem kell begépelni. Az azonosítást az appban aláírt jóváhagyás végzi.
Ami ezután jön, az már beállítás kérdése, nem szabály. Az egyik alkalmazás kérhet egy plusz megerősítést az appban, a másik jelszót, a harmadik mindkettőt. A jelszót időnként újra be is kérheti, hogy senki ne felejtse el teljesen. Mindez egyetlen konfigurációs képernyőn állítható, lásd az 5. lépést lejjebb.

1. lépés: Válasszon szolgáltatást

Használjon meglévő Notakey-szolgáltatást, ha a felhasználói már átfedésben vannak azzal az alkalmazással, amelyet most köt be, vagy hozzon létre újat (Services → Manage → New), ha azt szeretné, hogy ennek az alkalmazásnak saját, a többitől független jelszószabálya legyen. Az 5. lépésben beállított szabályzat a teljes szolgáltatásra vonatkozik, nem klienspéldányonként — ez a döntő szempont.

2. lépés: Kapcsolja be az OpenID Connectet

Nyissa meg a szolgáltatást, majd az OpenID Connect configuration → Configure menüpontban jelölje be az Enabled opciót. A többit egyelőre hagyja alapértéken — a Require password és a Require mfa beállítást tudatosan, az 5. lépésben fogja megadni, nem itt, véletlenül. Mentsen.

3. lépés: Másolja ki a végpontokat

Térjen vissza az OpenID Connect configuration oldalra, és kattintson a Show gombra. A Notakey ekkor már legenerálta a discovery dokumentumot, és a mögötte álló egyes végpontokat:

https://<your-dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration

A legtöbb OIDC-kompatibilis szoftvernek csak erre az egy URL-re van szüksége: illessze be egy „auto discovery” vagy „issuer” mezőbe, és az alkalmazás onnantól magától lekéri az authorization, token, userinfo és JWKS végpontokat. A <access-id> ugyanaz az azonosító, amely a szolgáltatás saját oldalán is látható.

4. lépés: Regisztrálja az alkalmazást kliensként

A szolgáltatáson belül: OpenID Connect configuration → Clients → New client. A Notakey ekkor generál Önnek egy Client ID-t és egy véletlenszerű Secretet.

Mentés előtt két dolgot érdemes tudni. Egyrészt a Secret mező el van takarva, és a Notakey többé nem mutatja meg, amint elnavigál az oldalról — másolja ki most, vagy jelölje ki a mezőt, és írjon bele egy saját választású titkot, ami ugyanúgy működik, csak könnyebb nyilvántartani. Másrészt a Redirect URIs mezőnek karakterről karakterre egyeznie kell azzal az URL-lel, amelyet az alkalmazás bejelentkezéskor visszaküld — egyetlen záró perjel, amelyet az alkalmazás nem küld el, elég ahhoz, hogy elromoljon (lásd a buktatót lejjebb).

Töltse ki a mezőket:

Description — bármi, ami alapján később felismeri.
Secret — másolja ki a generáltat, vagy írja felül a sajátjával.
Redirect URIs — az alkalmazás OAuth callback URL-je. Vesszővel válasszon el többet is, ha az alkalmazás több címen is elérhető.
Logout URI — hova irányítsa a böngészőt kijelentkezés után. Nem kötelező.

Ha regisztrált néhány alkalmazást, a szolgáltatás klienslistája így néz ki:

5. lépés: Irányítsa az alkalmazást a Notakey felé

A pontos lépések alkalmazásonként eltérnek, de a séma mindig ugyanaz: egy issuer vagy discovery URL, egy client ID, egy client secret. Két kidolgozott példa valódi, önállóan üzemeltetett eszközökből:

A Gitea ehhez saját CLI-parancsot ad — nincs webes űrlap, nincs újraindítás:

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 email

A Gitea bejelentkezési oldalán azonnal megjelenik egy „Sign in with notakey” gomb, a meglévő jelszavas űrlap mellett — semmi nem tűnik el.

A Proxmox VE ezt egy hitelesítési realmként kezeli, a már meglévők mellé, nem helyettük:

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

A --issuer-url itt a discovery URL a /.well-known/openid-configuration végződés nélkül — ezt a Proxmox maga fűzi hozzá. A --autocreate 1 az első sikeres bejelentkezéskor létrehoz egy megfelelő Proxmox-felhasználót, nulla jogosultsággal, amíg Ön kifejezetten nem ad neki valamit — véletlenül nem osztogat hozzáférést.

6. lépés: Állítsa be a jelszószabályzatot

Itt válik konkréttá az „adminisztrátor döntése” rész, ismét az OpenID Connect configuration → Configure oldalon:

Require password kikapcsolva, Require mfa bekapcsolva: ez az útmutató elején leírt jelszó nélküli folyamat. A bejelentkezés felhasználónév (vagy QR) plusz telefonos jóváhagyás, semmi más.
Require password bekapcsolva, Password cache 0-n hagyva: minden alkalommal jelszó is kell a jóváhagyás mellé — klasszikus kétfaktoros.
Require password bekapcsolva, a Password cache másodpercben megadva (mondjuk 2592000, azaz 30 nap): a mindennapi használat jelszó nélküli, a jelszót csak az ablak lejárta után kéri újra — pusztán azért, hogy sose merüljön feledésbe. Az Mfa cache ugyanígy működik a jóváhagyási lépésre, ha azt is gyorsítótárazni szeretné.

Mivel ez a beállítás a teljes szolgáltatásra vonatkozik, egy olyan alkalmazásnak, amelynek a szomszédjaitól eltérő szabályzatra van szüksége, saját szolgáltatás kell — vissza az 1. lépés döntéséhez.

Ha valami nem működik

A redirect_uri mismatch hiba szinte mindig egy záró perjelre vezethető vissza: egyes alkalmazások https://app.example.com formában küldik, mások https://app.example.com/ formában, a Notakey pedig karakterre pontosan egyezteti a stringet. Nézze meg az nginx- vagy az alkalmazás access logjában a ténylegesen küldött redirect_uri= értéket, és pontosan azt regisztrálja.
Ha a discovery URL 404-et ad, ellenőrizze, hogy a 2. lépésben az Enabled valóban el lett-e mentve — a leggyakoribb hiba egy helyesnek tűnő, de sosem elküldött konfigurációs oldal.
A szolgáltatás alatti Authentication activities napló minden olyan kísérletet mutat, amely eljutott a Notakeyig. Ha egy kísérlet ott meg sem jelenik, az azt jelenti, hogy az alkalmazás el sem jutott az authorization végpontig — először a client ID-t és a discovery URL-t ellenőrizze.

Amit ez az útmutató szándékosan kihagy

A kizárólag SAML-t beszélő alkalmazások — Google Workspace, AWS és hasonlók — klasszikus SAML 2.0 integrációja a Notakey külön SAML identity providerén megy keresztül, nem a fenti OIDC-úton. Az LDAP/Active Directory mint felhasználói forrás, a multi-tenant beállítások és az egyedi márkázás szintén ezen az útmutatón kívül esnek. Mindez megtalálható a CLI és API referenciában, teljes paramétertáblákkal; ez az útmutató a gyors út a semmiből a működő, jelszó nélküli bejelentkezésig.

Nézze meg, mielőtt megépíti

A bejelentkezési élményt leggyorsabban úgy ítélheti meg, ha maga is kipróbálja a jóváhagyási folyamatot: próbálja ki az élő demót, és körülbelül két perc alatt aláír egy kérést a telefonjáról, vagy kérjen bemutatót, és feltérképezzük, hogyan illeszthetők az Ön alkalmazásai és jelszószabálya egy, a saját infrastruktúráján futó pilot projektbe.