Mit Znosin anmelden

Website registrieren

Installieren Sie OAuth aus dem Znosin-Katalog, öffnen Sie „Meine Websites“ und fügen Sie Ihre Website hinzu. Ein Konto kann bis zu 20 Integrationen besitzen. Verwenden Sie für eine Organisation ein eigenes Betreiberkonto, setzen Sie ein Passwort und prüfen Sie dessen Geräte.

confidential

Website mit Server

Ein vertraulicher Client verwendet client_secret_basic. Speichern Sie das Client Secret in einem serverseitigen Geheimnisspeicher: Es wird nur einmal angezeigt.

public

Browseranwendung

Ein öffentlicher Client nutzt die Authentifizierungsmethode none ohne Client Secret. PKCE-Verifier und Tokens gehören weder in URLs noch in Protokolle.

Registrieren Sie bis zu 10 exakte Weiterleitungs-URLs. HTTPS ist erforderlich; HTTP ist nur für localhost, 127.0.0.1 oder [::1] erlaubt. Platzhalter, Fragmente und Zugangsdaten in URLs werden abgewiesen. Trennen Sie Entwicklung und Produktion nach Möglichkeit.

Die Client ID ist öffentlich. Eine Secret-Rotation widerruft sofort das alte Secret, Codes und Zugriffstokens. Geänderte Weiterleitungs-URLs oder die Deaktivierung widerrufen ebenfalls bestehende Freigaben. Speichern Sie Secrets niemals in Git, Frontend-Code oder Screenshots.

OIDC-Bibliothek konfigurieren

Einstellung	Wert
Issuer	`https://znosin.com`
Discovery	`https://znosin.com/.well-known/openid-configuration`
Autorisierungsablauf	`authorization_code` · `response_type=code` · `response_mode=query`
Berechtigungen	`openid profile email`
PKCE	S256, für beide Client-Typen erforderlich
ID-Token-Signatur	RS256; öffentliche Schlüssel über jwks_uri im Discovery-Dokument

Erzeugen Sie vor der Weiterleitung unabhängige, kryptografisch zufällige Werte für state, nonce und code_verifier. Speichern Sie diese in der Serversitzung des Besuchers, bei öffentlichen Clients in der Browsersitzung. State und Nonce: 16–512 Zeichen, mindestens 32 zufällige Bytes verwenden. Verifier: 43–128 nicht reservierte ASCII-Zeichen. Verwenden Sie keinen Ablauf erneut.

Autorisierungsanfrage

GET https://znosin.com/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=EXACT_REGISTERED_URL&
  response_type=code&scope=openid%20profile%20email&
  state=RANDOM_STATE&nonce=RANDOM_NONCE&
  code_challenge=BASE64URL_SHA256_VERIFIER&
  code_challenge_method=S256

Kodieren Sie jeden Parameterwert für URLs. openid ist erforderlich; optional wird prompt=consent unterstützt. Stille Anmeldung, erzwungene erneute Anmeldung mit max_age, Request Objects und andere Response Modes werden nicht unterstützt.

Rückleitung verarbeiten

Verbrauchen Sie den gespeicherten Ablauf einmalig. Prüfen Sie den ursprünglichen state, die Gültigkeit und die exakte Übereinstimmung von iss und Issuer. Erstellen Sie bei error=access_denied keine Sitzung. Verwenden Sie ungeprüfte Callback-Parameter niemals als Weiterleitungsziel.
Tauschen Sie den Code innerhalb von 60 Sekunden per POST-Formulardaten an /oauth/token aus. Senden Sie grant_type, client_id, redirect_uri, code und code_verifier. Der Code ist einmalig. Vertrauliche Clients benötigen zusätzlich HTTP Basic: Client ID und Client Secret einzeln als Formularwerte kodieren, mit Doppelpunkt verbinden und Base64-kodieren. Secrets im Anfragekörper werden nicht akzeptiert.
Prüfen Sie mit Ihrer OIDC-Bibliothek RS256-Signatur, exakten Issuer, Audience, Ablaufzeit, Ausstellungszeit und sitzungsgebundene Nonce. Prüfen Sie auch azp, falls vorhanden. Bloßes Dekodieren des JWT reicht nicht.
Suchen oder erstellen Sie den lokalen Benutzer anhand von iss + sub. Erneuern Sie anschließend die lokale Sitzungs-ID. Nickname, Anzeigename und E-Mail können sich ändern und sind keine Identitätsschlüssel.

Code-Austausch · vertraulicher Client

POST https://znosin.com/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_FORM_ENCODED_ID_AND_SECRET

grant_type=authorization_code&
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
code=AUTHORIZATION_CODE&
code_verifier=ORIGINAL_VERIFIER

Das Beispiel enthält Platzhalter, keine echten Zugangsdaten. Öffentliche Clients lassen den Authorization-Header weg. Beide Client-Typen senden den ursprünglichen PKCE-Verifier und die exakt registrierte Weiterleitungs-URL. Alle Werte im Anfragekörper müssen formularkodiert sein.

Profil und Berechtigungen

Die Antwort enthält ein 5 Minuten gültiges ID-Token und ein 1 Stunde gültiges opakes Zugriffstoken. Rufen Sie /oauth/userinfo mit Authorization: Bearer ACCESS_TOKEN auf. Dessen sub muss dem geprüften ID-Token entsprechen.

Berechtigung	Zurückgegebene Claims
`openid`	`sub`
`profile`	`name`, `preferred_username`, `picture` (öffentliche Avatar-URL)
`email`	`email`, `email_verified`

email_verified ist derzeit false. Das Bereitstellen eines Postfachs bestätigt nicht den Besitz einer E-Mail-Adresse. Verknüpfen Sie unbestätigte Adressen niemals automatisch mit einem bestehenden Passwort- oder Fremdanbieterkonto. Verlangen Sie zuvor eine Anmeldung am bestehenden Konto.

Passwörter, Chats, E-Mail-Inhalte, Dateien und Agentenrechte werden nicht weitergegeben. Nutzer können den Zugriff im Profil unter den Website-Freigaben widerrufen. Dies sperrt UserInfo und neue Code-Austausche, beendet jedoch weder die Sitzung Ihrer Website noch ein bereits ausgestelltes, offline prüfbares ID-Token. Ihre Website verwaltet Sitzungen und Abmeldung selbst.

Betrieb und Grenzen

CORS für öffentliche Clients erlaubt nur exakt registrierte Redirect-Origins. Vertrauliche Clients tauschen Codes zwischen Servern aus. Leiten Sie den Basic-Header niemals an JWKS, UserInfo oder Redirects weiter. Speichern Sie nur benötigte Zugriffe, entfernen Sie Codes und Tokens aus Protokollen und begrenzen Sie Callback-Anfragen. Token-Limits gelten pro IP; beachten Sie Retry-After bei HTTP 429.

Die Verwaltung erfordert eine angemeldete Znosin-Browsersitzung des Eigentümers mit Origin-Prüfung. Agententokens können keine Websites registrieren oder Zugriff genehmigen. Die Selbstregistrierung erfolgt über die OAuth-App, nicht über unauthentifizierte dynamische Client-Registrierung. Der Website-Name stammt vom Eigentümer und ist kein Prüfsiegel; die Zustimmung zeigt den tatsächlichen Redirect-Origin.

Der Anbieter implementiert ein begrenztes OIDC-Code-Flow-Profil ohne OpenID-Konformitätszertifizierung. Refresh Tokens, föderierte Abmeldung, PAR, DPoP und automatische RSA-Schlüsselrotation sind nicht implementiert. Bestehende öffentliche Clients bleiben unterstützt.

Protokollspezifikationen

OAuth Security Best Current Practice ↗OpenID Connect Core ↗

Mit Znosin anmelden

01Website registrieren