Authn.tech
Startseite
  • SAML 2.0
  • OAuth 2.0
  • OIDC
  • WebAuthn / Passkey
  • MFA / TOTP
  • LDAP
  • Alle Tools
  • JWT dekodieren
  • JWT signieren
  • JWK erzeugen
  • JWK → PEM
  • PEM → JWK
  • PKCE erzeugen
  • OIDC Discovery
  • TOTP
  • WebAuthn
  • SAML-Codec
  • SAML Metadata
  • SAML Response
  • X.509-Zertifikat
  • PEM prüfen
  • Base64URL
  • LDAP-Filter
  • Übersicht & Rollen
  • OIDC Mock
  • SAML Mock
  • Mail-Server
  • LDAP-Verzeichnis
  • OIDC-Login-Demo
  • SAML-Login-Demo
  • 简体中文
  • English
  • Deutsch
GitHub
Startseite
  • SAML 2.0
  • OAuth 2.0
  • OIDC
  • WebAuthn / Passkey
  • MFA / TOTP
  • LDAP
  • Alle Tools
  • JWT dekodieren
  • JWT signieren
  • JWK erzeugen
  • JWK → PEM
  • PEM → JWK
  • PKCE erzeugen
  • OIDC Discovery
  • TOTP
  • WebAuthn
  • SAML-Codec
  • SAML Metadata
  • SAML Response
  • X.509-Zertifikat
  • PEM prüfen
  • Base64URL
  • LDAP-Filter
  • Übersicht & Rollen
  • OIDC Mock
  • SAML Mock
  • Mail-Server
  • LDAP-Verzeichnis
  • OIDC-Login-Demo
  • SAML-Login-Demo
  • 简体中文
  • English
  • Deutsch
GitHub
  • Mock-Server

    • Übersicht & Rollen
    • OIDC Mock
    • SAML Mock
    • Mail-Server
    • LDAP-Verzeichnis
    • OIDC-Login-Demo
    • SAML-Login-Demo

Mock-Authentifizierungsserver

Service-Adresse: https://mock.authn.tech/

Dies ist ein Einsatzbereiter Online-Mock-Authentifizierungsdienst, bereitgestellt auf Cloudflare Workers. Authentifizierungs-/Autorisierungsprozesse erfordern normalerweise die Zusammenarbeit mehrerer Rollen (Tokensaussteller, Tokenkonsumenten, geschützte APIs...), es ist mühsam, sie alle selbst aufzubauen. Dieses Mock implementiert alle diese Rollen fertig und stellt sie ins öffentliche Netz, Sie können:

  • Gemeinsame Entwicklung: Bei der Client-Entwicklung ist es nicht notwendig, zunächst einen Keycloak / ADFS einzurichten, verbinden Sie sich direkt mit dem Mock dieser Seite; umgekehrt können auch nur Backend-Entwickler den Mock-Client dieser Seite verwenden, um Ihren Service zu testen.
  • Integrationstests: In CI mit festen, vorhersehbaren Antworten Ihren Authentifizierungsintegrationscode validieren (Anhängen von &user=alice ermöglicht Skripte ohne Interaktion).
  • Lernen und Üben: In Kombination mit Protokoll-Dokumentation können Sie beobachten, wie jeder Schritt der Nachricht aussieht.

Rollen und Terminologie

Nutzen Sie die vier Rollennamen, wie von OAuth 2.0 (RFC 6749) definiert; OIDC (OpenID Connect Core) und SAML 2.0 sind nur unterschiedliche Benennungen derselben Rollen. Die folgende Tabelle reiht nach "gleiche Rolle, unterschiedliche Benennungen in verschiedenen Spezifikationen":

OAuth 2.0 (RFC 6749)OIDCSAML 2.0Deutsch / VerantwortungDieses Mock
Resource OwnerEnd-UserPrincipal (Subject)Ressourceneigentümer / Endbenutzer, erteilt ZustimmungTest-Benutzer alice / bob
Authorization ServerOpenID Provider (OP)Identity Provider (IdP)Aussteller: verifiziert Identität, stellt Token / Assertion aus/oidc/*, /saml/idp/*
ClientRelying Party (RP)Service Provider (SP)Konsument: initiiert Login, validiert Token / Assertion/rp/, /saml/sp/*
Resource ServerResource Server——Ressourcenserver / geschützte API/rs/api

RFC 6749 nutzt die Namen Resource Owner / Client / Authorization Server / Resource Server. OIDC nennt Authorization Server OP, Client RP; SAML nennt es IdP / SP — alle sind Aliase derselben Rollen. Unter diesen ist Resource Owner eine Person (kein ansprechbarer Dienst), diese Site wird durch die Auswahlseite mit alice / bob dargestellt. Daher besprechen wir im Folgenden nur die ansprechbaren Dienstollen.

Die Rollen, Endpunkte und Aufrufschritte auf beiden Seiten sind:

  • 🔷 OIDC / OAuth2 Mock —— OP / RP / RS drei Rollen + Autorisierungscode + PKCE Aufruffolge
  • 🔶 SAML Mock —— IdP / SP zwei Rollen + Web Browser SSO Aufruffolge
  • 📬 Mail-Server —— Empfangen Sie @authn.tech E-Mails mit Email Routing, zeigen Sie online / API an und extrahieren Sie Einmal-Verifizierungscodes
  • 🗂 LDAP-Verzeichnis —— HTTP/JSON-Verzeichnissuche-Emulator, wertet RFC 4515-Filter gegen ein Beispielverzeichnis aus (nicht das echte LDAP-Protokoll)

Nur zum Testen

Die Signaturprivatsschlüssel sind öffentlich im Quellcode verfügbar, jeder kann von diesem Service ausgegebene Token / Assertions fälschen; Autorisierungscodes garantieren nicht Einzelnutzung (zustandslose Implementierung). Kein Produktionssystem sollte Assertions oder Token dieses Mock-Services vertrauen.

Mischen: Ersetzen Sie einen Teil durch Ihren eigenen Service

Der Wert des Mock liegt in nur mocken Sie den Teil, den Sie noch nicht haben, nutzen Sie Ihren echten Service für den Rest. Häufige Kombinationen:

Was Sie bereits habenNutzen Sie Mock umWie zu verbinden
RP / ClientMock OPRichten Sie issuer des RP auf https://mock.authn.tech (automatische Erkennung /.well-known/openid-configuration)
OP / AutorisierungsserverMock RPÖffnen Sie /rp/ Konsole, geben Sie Ihren issuer und client_id ein, und whitelist Sie …/rp/callback
Geschützte API aber fehlende Token-QuelleMock OPNutzen Sie Mock OP mit client_credentials oder Autorisierungscode um access_token zu erhalten, verwenden Sie es dann mit Ihrer API
API-Client aber fehlende geschützte RessourceMock RSVerwenden Sie Token, die von Mock OP signiert wurden, auf /rs/api, validieren Sie Ihres Clients 401 / 403 Behandlung
SP / vertrauenswürdige AnwendungMock IdPImportieren Sie /saml/idp/metadata in Ihren SP
IdPMock SPKonfigurieren Sie Ihr IdP-Metadata auf Mock SP, oder nutzen Sie IdP-initiiert zu Mock SP ACS

Einheitliche Idee: Aussteller (OP / IdP) und Konsument (RP / SP) erscheinen immer paarweise, ergänzen Sie den fehlenden Teil, lassen Sie Mock mit Ihrem echten Service verbinden, Sie können den kompletten Prozess durchlaufen.

Implementierungsfortschritt und Anforderungen sind willkommen auf GitHub.

Zuletzt aktualisiert: 06.07.26, 08:43
Mitwirkende: linux, Claude Opus 4.8
Next
OIDC Mock