OIDC · OAuth 2.0

Single Sign-On, verständlich erklärt.

EURIP SSO ist ein professioneller OIDC Provider für Unternehmen. Wir liefern klare Workflows, saubere Sicherheitsgrenzen und vollständige Audit-Trails.

Kurzfassung

  • SSO Ein Login, viele Apps – zentraler Zugriff.
  • OIDC Identity-Layer auf OAuth 2.0.
  • Audit Nachvollziehbarkeit für Sicherheit & Compliance.

So funktioniert der OIDC Authorization Code Flow

Der Standard-Flow für Browser-Logins. EURIP SSO trennt Identität und API-Zugriff konsequent:

  1. Der Client leitet den Nutzer zu /oidc/authorize weiter.
  2. Login + Consent werden geprüft und dokumentiert.
  3. Der Client tauscht den Code gegen Tokens via /oidc/token.
  4. Benutzerinformationen kommen via /oidc/userinfo.
Wichtig: id_token ist für Identität, access_token ausschließlich für API-Zugriff.

Ablauf in 60 Sekunden

1
Redirect

App schickt den Nutzer zum Login (Authorization Endpoint).

2
Login + Consent

Nutzer meldet sich an und bestätigt die Scopes.

3
Code

App erhält einen kurzen Authorization Code.

4
Tokens

App tauscht Code gegen Tokens und ruft UserInfo ab.

Ziel: Ein sicherer, nachvollziehbarer Login ohne Datenlecks.

Sicherheitsfeatures im Überblick

State & Nonce

Schutz gegen CSRF und Replay-Angriffe im Login-Prozess.

Kurze TTLs

Authorization Codes und Tokens laufen bewusst kurz.

Consent-Flow

Nutzer entscheiden transparent über Scopes und Zugriff.

Audit-Trails

Jede sicherheitsrelevante Aktion wird protokolliert.

OIDC, OAuth 2.0, Discovery & JWKS – kurz erklärt

OAuth 2.0 regelt, wie Apps Zugang zu APIs bekommen. OpenID Connect (OIDC) ergänzt Identität (wer du bist) – damit SSO möglich wird.

Discovery

Über /.well-known/openid-configuration erfährt der Client alle Endpunkte – ohne Hardcoding.

JWKS

Über /.well-known/jwks.json holt der Client die öffentlichen Schlüssel, um Token-Signaturen zu prüfen.

id_token

Enthält Identitäts-Claims (z.B. sub, email) und ist signiert.

access_token

Dient nur für API-Zugriff und steuert, welche Daten erlaubt sind.

Kurz gesagt: OAuth 2.0 gibt Zugriff, OIDC gibt Identität.

Mini‑Sequenzdiagramm

User -> Client: Login klicken
Client -> EURIP SSO: /oidc/authorize (state, nonce)
EURIP SSO -> User: Login + Consent
EURIP SSO -> Client: redirect mit code
Client -> EURIP SSO: /oidc/token (code)
EURIP SSO -> Client: id_token + access_token
Client -> EURIP SSO: /oidc/userinfo (access_token)
EURIP SSO -> Client: Claims

HTTP‑Beispiele (curl)

Hinweis: In Produktion immer https nutzen. In der lokalen Entwicklung kann http ausreichend sein.
BASH Authorization (Beispiel)
https://sso.eurip.com/oidc/authorize?client_id=your-app&redirect_uri=https://app.example.com/auth/callback&response_type=code&scope=openid%20profile%20email&state=...&nonce=...
curl -i "https://sso.eurip.com/oidc/authorize?client_id=your-app&redirect_uri=https://app.example.com/auth/callback&response_type=code&scope=openid%20profile%20email&state=...&nonce=..."
BASH Token Exchange (Beispiel)
https://sso.eurip.com/oidc/token
curl -X POST https://sso.eurip.com/oidc/token -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=authorization_code&code=...&client_id=your-app&redirect_uri=https://app.example.com/auth/callback"
BASH UserInfo (Beispiel)
https://sso.eurip.com/oidc/userinfo
curl -H "Authorization: Bearer <access_token>" https://sso.eurip.com/oidc/userinfo
BASH Discovery (Beispiel)
https://sso.eurip.com/.well-known/openid-configuration
curl https://sso.eurip.com/.well-known/openid-configuration
BASH JWKS (Beispiel)
https://sso.eurip.com/.well-known/jwks.json
curl https://sso.eurip.com/.well-known/jwks.json
JSON JWKS Antwort (gekürzt)
{
  "keys": [
    {
      "kty": "RSA",
      "kid": "2026-01",
      "use": "sig",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    }
  ]
}

Warum Signaturen und JWKS wichtig sind

Ein id_token ist nur vertrauenswürdig, wenn die Signatur stimmt. Über JWKS holt der Client den passenden Public Key (via kid im Header).

BASH Signatur‑Prüfung (Kurzform)
1) kid aus JWT Header lesen
2) passenden Key aus JWKS holen
3) Signatur + Claims prüfen

Beispiel: id_token Payload

Ein signierter JWT enthält Claims, die Identität und Gültigkeit beschreiben.

JSON id_token Payload (Beispiel)
{
  "iss": "https://sso.example.com",
  "aud": "my-app",
  "sub": "user-123",
  "iat": 1714820000,
  "exp": 1714823600,
  "nonce": "n-0S6_WzA2Mj",
  "email": "user@example.com"
}
  • iss: Wer hat das Token ausgestellt?
  • aud: Für welche App ist es gedacht?
  • sub: Stabile User‑ID im SSO.
  • iat/exp: Gültigkeit (Zeitfenster).
  • nonce: Bindet Token an die Login‑Session.

Typische Fehler & schnelle Lösungen

  • state mismatch: State serverseitig speichern und vergleichen.
  • redirect_uri falsch: Exakter Match mit Client‑Konfiguration.
  • JWKS Prüfung fehlt: Signatur immer verifizieren.
  • Clock Skew: Kleine Toleranz bei iat/exp einbauen.
  • openid fehlt: Ohne openid kein OIDC‑Login.

Was dein Team erhält

  • OIDC Standardisierte Endpunkte und JWKS.
  • Audit Events wie TOKEN_ISSUED, CONSENT_GRANTED.
  • Admin Clients, Scopes, Redirect-URIs zentral steuerbar.

Sicherheit im Fokus

  • State Schutz gegen CSRF und Replay.
  • Nonce Bindet ID Tokens an eine Sitzung.
  • TTL Kurzlebige Codes und Tokens.

Transparente Workflows

Jeder sicherheitsrelevante Schritt wird als Audit-Event erfasst. So siehst du im Admin-Bereich nachvollziehbar, was wann passiert ist.

AUTH_REQUEST_RECEIVED
CONSENT_REQUIRED
CONSENT_GRANTED
AUTH_CODE_ISSUED
TOKEN_ISSUED

Integration in deine Apps

Wir dokumentieren die Anbindung Schritt für Schritt, inklusive Beispiel-Config, Redirect-Handling und Signaturprüfung.

Mehrsprachigkeit ist vorbereitet – Inhalte können später in weitere Sprachen überführt werden.

Feature‑Matrix

Bereich Beschreibung Status
Authorization Code Flow Standard-Flow für sichere Browser-Logins. Live
PKCE (S256 + plain) Schützt öffentliche Clients (SPA, Mobile, CLI). Live
Discovery + JWKS Automatische Endpunkte + Signaturprüfung. Live
UserInfo Endpoint Scopes steuern Claims, minimaler Datenzugriff. Live
Refresh Tokens Token Rotation mit Replay-Detection. Live
Token Revocation Tokens aktiv invalidieren (RFC 7009). Live
Token Introspection Token-Gültigkeit prüfen (RFC 7662). Live
Device Code Flow Login für CLI, Smart TV, IoT (RFC 8628). Live
Front-Channel Logout Iframe-basierte Client-Benachrichtigung. Live
Back-Channel Logout HTTP POST mit Logout Token (async). Live

Unterstützte Grant Types

Bereich Beschreibung Status
Authorization Code Standard-Flow für Browser-Logins (RFC 6749). Empfohlen
Authorization Code + PKCE Für SPAs, Mobile Apps, CLI (RFC 7636). Empfohlen
Refresh Token Session verlängern mit Token Rotation. Live
Client Credentials Machine-to-Machine ohne User-Kontext. Live
Device Code Smart TV, CLI, IoT-Geräte (RFC 8628). Live

Session & Logout

  • Live Front-Channel Logout – Iframe-basiert
  • Live Back-Channel Logout – HTTP POST (async)
  • Live RP-Initiated Logout – End-Session Endpoint
  • Live Session Management – postMessage-basiert

FAQ – kurz & klar

Nein, wir starten schlank und skalieren mit.

OIDC & OAuth 2.0 mit JWKS und Discovery.

Mit klarer Doku und Beispiel-Flow in wenigen Stunden.

Für Teams, die Verantwortung tragen

EURIP SSO liefert Sicherheit und Transparenz, ohne Entwickler auszubremsen. Ideal für Produktteams, die sichere Anmeldungen sauber dokumentiert und nachvollziehbar betreiben wollen.