Passwortloses SSO mit Notakey: eine Schritt-für-Schritt-Anleitung zur Konfiguration

Am Ende dieser Anleitung melden sich Ihre Nutzer per Telefon-Bestätigung an einer App an: Benutzernamen eingeben oder QR-Code scannen, dann in der Notakey-App bestätigen. Kein Passwort auf der Anmeldeseite. Das Passwort existiert weiterhin, hat aber nur noch eine einzige Pflichtaufgabe: Es wird genau einmal gebraucht, bei der Geräteregistrierung, um den Schlüssel des Nutzers zu erzeugen. Alles danach ist eine Frage Ihrer Richtlinie – und diese Anleitung zeigt genau, wo jede einzelne davon eingestellt wird.

Jeder Notakey-Service – auch die, die Sie bereits für VPN-, Windows- oder WLAN-2FA einsetzen – kann zugleich als OpenID-Connect-Provider arbeiten. Dafür brauchen Sie kein separates Produkt: Sie aktivieren OIDC für einen Service im Dashboard, registrieren die App, die ihn als Client nutzen soll, und richten diese App auf die Endpunkte aus, die Notakey Ihnen liefert. Keine SAML-Zertifikate, kein zusätzlicher Identity-Provider-Server zum Betreiben.

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

(Klassische Enterprise-Apps, die ausschließlich SAML sprechen – Google Workspace, AWS – benötigen stattdessen Notakeys separaten SAML-Identity-Provider; wo Sie den finden, steht im letzten Abschnitt.)

Wie das Passwort hier tatsächlich funktioniert

Hier lohnt sich Präzision, denn „passwortlos“ wird gern pauschal behauptet:

• Das Onboarding ist das einzige Pflichtpasswort. Im Dashboard gesetzt oder aus Active Directory übernommen, wird es genau einmal geprüft: wenn der Nutzer sein Gerät registriert und sein Schlüssel in der sicheren Hardware des Telefons erzeugt wird.
• Die tägliche Anmeldung kommt ohne aus. Der Nutzer tippt einen Benutzernamen oder scannt einen QR-Code; die Anmeldeseite lässt sich auf reines Scannen reduzieren – nichts, wo überhaupt etwas eingetippt werden könnte. Die Identitätsprüfung ist die signierte Bestätigung in der App.
• Alles danach ist eine Einstellung, keine feste Regel. Die eine App verlangt eine zusätzliche Bestätigung in der App, die nächste ein Passwort, eine dritte beides. Sie können das Passwort auch in festen Abständen erneut abfragen, damit es nicht ganz in Vergessenheit gerät. Das alles liegt auf einem einzigen Konfigurationsbildschirm, den Schritt 5 weiter unten behandelt.

Schritt 1: Einen Service auswählen

Verwenden Sie einen bestehenden Notakey-Service, wenn sich dessen Nutzerkreis bereits mit dem der anzubindenden App überschneidet. Legen Sie einen neuen an (Services → Manage → New), wenn diese App eine eigene, von allem anderen unabhängige Passwortrichtlinie haben soll. Ausschlaggebend ist: Die Richtlinie aus Schritt 5 gilt für den gesamten Service, nicht pro Client.

Schritt 2: OpenID Connect aktivieren

Öffnen Sie den Service, dann OpenID Connect configuration → Configure, und aktivieren Sie Enabled. Lassen Sie den Rest vorerst auf den Standardwerten – Require password und Require mfa stellen Sie bewusst in Schritt 5 ein, nicht schon hier aus Versehen. Speichern.

Schritt 3: Endpunkte kopieren

Zurück auf OpenID Connect configuration, klicken Sie auf Show. Notakey hat ein Discovery-Dokument erzeugt; dahinter liegen die einzelnen Endpunkte:

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

Die meiste OIDC-fähige Software braucht nur diese eine URL: in ein Feld namens „Auto Discovery“ oder „Issuer“ eingetragen, holt sich die App Authorization-, Token-, Userinfo- und JWKS-Endpunkte selbst. <access-id> ist dieselbe ID, die auch auf der Seite des Service selbst angezeigt wird.

Schritt 4: Anwendung als Client registrieren

Im Service unter OpenID Connect configuration → Clients → New client. Notakey generiert dabei eine Client ID und ein zufälliges Secret für Sie.

Zwei Dinge sollten Sie vor dem Speichern wissen: Das Secret-Feld ist maskiert, und sobald Sie die Seite verlassen, zeigt Notakey es Ihnen nicht noch einmal – kopieren Sie es also jetzt. Oder markieren Sie das Feld und fügen Sie ein eigenes Secret Ihrer Wahl ein, was genauso gut funktioniert und sich leichter im Blick behalten lässt. Und das Feld Redirect URIs muss zeichengenau zu der URL passen, die die App beim Login zurückschickt – schon ein abschließender Schrägstrich, den die App nicht mitsendet, genügt, damit es nicht klappt (siehe den Fallstrick weiter unten).

Tragen Sie ein:

• Description – was auch immer Sie später wiedererkennen lässt.
• Secret – das generierte übernehmen oder durch ein eigenes ersetzen.
• Redirect URIs – die OAuth-Callback-URL der App. Mehrere Werte durch Komma trennen, wenn die App unter mehreren Adressen erreichbar ist.
• Logout URI – wohin der Browser nach dem Abmelden geschickt wird. Optional.

Sobald Sie ein paar Apps registriert haben, sieht die Client-Liste des Diensts so aus:

Schritt 5: App auf Notakey ausrichten

Die genauen Schritte hängen von der App ab, das Grundmuster aber ist immer dasselbe: eine Issuer- oder Discovery-URL, eine Client-ID, ein Client-Secret. Zwei durchgerechnete Beispiele aus echten selbstgehosteten Tools:

Gitea bringt dafür einen fertigen CLI-Befehl mit – kein Webformular, kein Neustart nötig:

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

Auf Giteas Anmeldeseite erscheint sofort ein Button „Sign in with notakey“, neben dem bestehenden Passwortformular – nichts wird entfernt.

Proxmox VE behandelt es als eigenen Authentifizierungs-Realm, zusätzlich zu den bereits vorhandenen:

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 ist hier die Discovery-URL ohne das abschließende /.well-known/openid-configuration – das hängt Proxmox selbst an. --autocreate 1 legt bei der ersten erfolgreichen Anmeldung einen passenden Proxmox-Benutzer an, zunächst ganz ohne Rechte, bis Sie welche explizit vergeben; Zugriff verteilt es nicht aus Versehen.

Schritt 6: Passwortrichtlinie festlegen

Hier wird die „Entscheidung des Admins“ konkret, wieder auf OpenID Connect configuration → Configure:

• Require password deaktiviert, Require mfa aktiviert: der passwortlose Ablauf vom Anfang dieser Anleitung. Die Anmeldung besteht nur aus Benutzername (oder QR-Code) plus Bestätigung am Telefon, sonst nichts.
• Require password aktiviert, Password cache auf 0 belassen: Passwort bei jeder Anmeldung, zusätzlich zur Bestätigung – klassische Zwei-Faktor-Authentifizierung.
• Require password aktiviert mit einem Password cache in Sekunden (etwa 2592000 für 30 Tage): im Alltag passwortlos, das Passwort wird erst wieder abgefragt, wenn dieses Zeitfenster verstrichen ist – einzig damit es nicht ganz in Vergessenheit gerät. Mfa cache funktioniert nach demselben Prinzip für den Bestätigungsschritt, falls Sie auch den irgendwann zwischenspeichern wollen.

Da diese Einstellung für den gesamten Service gilt, gehört eine App mit abweichenden Anforderungen in einen eigenen Service – zurück zur Entscheidung aus Schritt 1.

Wenn etwas nicht funktioniert

• Ein redirect_uri mismatch-Fehler bedeutet fast immer einen Schrägstrich am Ende: Manche Apps senden https://app.example.com, andere https://app.example.com/, und Notakey vergleicht die Zeichenkette exakt. Prüfen Sie Ihre nginx- oder App-Access-Logs auf das tatsächlich gesendete redirect_uri= und registrieren Sie genau diesen Wert.
• Liefert die Discovery-URL einen 404, prüfen Sie, ob Enabled in Schritt 2 wirklich gespeichert wurde – eine Konfigurationsseite, die richtig aussieht, aber nie abgeschickt wurde, ist der häufigste Fehler.
• Das Log Authentication activities im Service zeigt jeden Versuch, der Notakey tatsächlich erreicht hat. Taucht ein Versuch dort gar nicht erst auf, ist die App nie bis zum Authorization-Endpunkt vorgedrungen – prüfen Sie zuerst Client-ID und Discovery-URL.

Was diese Anleitung bewusst auslässt

Klassische SAML-2.0-Integrationen für Apps, die ausschließlich SAML sprechen – Google Workspace, AWS und Ähnliches –, laufen über Notakeys separaten SAML-Identity-Provider, nicht über den OIDC-Weg oben. LDAP/Active Directory als Nutzerverzeichnis, Multi-Tenant-Setups und individuelles Branding liegen ebenfalls außerhalb dieser Anleitung. All das findet sich in der CLI- und API-Referenz mit vollständigen Parametertabellen; diese Anleitung ist der schnelle Weg von null zu einer funktionierenden, passwortlosen Anmeldung.

Erst ausprobieren, dann einrichten

Am schnellsten lässt sich die Anmeldeerfahrung beurteilen, wenn Sie den Bestätigungsablauf selbst ausprobieren: Testen Sie die Live-Demo und signieren Sie eine Anfrage in etwa zwei Minuten von Ihrem Telefon aus, oder fordern Sie eine Demo an, und wir bilden Ihre Anwendungen und Ihre Passwortrichtlinie in einem Pilotprojekt auf Ihrer eigenen Infrastruktur ab.