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:

Der Client leitet den Nutzer zu /oidc/authorize weiter.
Login + Consent werden geprüft und dokumentiert.
Der Client tauscht den Code gegen Tokens via /oidc/token.
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

Redirect

App schickt den Nutzer zum Login (Authorization Endpoint).

Nutzer meldet sich an und bestätigt die Scopes.

Code

App erhält einen kurzen Authorization Code.

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 (Text)

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.

Code Authorization (Beispiel)

https://sso-beta.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-beta.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=..."

Code Token Exchange (Beispiel)

https://sso-beta.eurip.com/oidc/token

curl -X POST https://sso-beta.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"

Code UserInfo (Beispiel)

https://sso-beta.eurip.com/oidc/userinfo

curl -H "Authorization: Bearer <access_token>" https://sso-beta.eurip.com/oidc/userinfo

Code Discovery (Beispiel)

https://sso-beta.eurip.com/.well-known/openid-configuration

curl https://sso-beta.eurip.com/.well-known/openid-configuration

Code JWKS (Beispiel)

https://sso-beta.eurip.com/.well-known/jwks.json

curl https://sso-beta.eurip.com/.well-known/jwks.json

Code 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).

Code 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.

Code 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.

Leistungsübersicht Integration

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
Discovery + JWKS	Automatische Endpunkte + Signaturprüfung.	Live
UserInfo Endpoint	Scopes steuern Claims, minimaler Datenzugriff.	Live
PKCE	Schützt öffentliche Clients (SPA/Mobile).	Geplant
Refresh Tokens	Längere Sessions ohne erneuten Login.	Geplant
Token Revocation	Tokens aktiv invalidieren.	Geplant

Feature-Status (Ist vs. Geplant)

Bereich	Beschreibung	Status
Authorization Code Flow	Standard-Flow für sichere Browser-Logins.	Live
Discovery + JWKS	Automatische Endpunkte + Signaturprüfung.	Live
UserInfo Endpoint	Scopes steuern Claims, minimaler Datenzugriff.	Live
Consent + Remember	Transparente Freigaben mit Remember-Option.	Live
PKCE	Schützt öffentliche Clients (SPA/Mobile).	Geplant
Client Secrets	Stärkere Client‑Authentifizierung.	Geplant
Refresh Tokens	Längere Sessions ohne erneuten Login.	Geplant
Token Revocation	Tokens aktiv invalidieren.	Geplant

Diese Übersicht hilft dir, aktuelle Features und den nächsten Ausbau zu verstehen.

Was wir als Nächstes anbieten

PKCE für mobile und SPA-Clients.
Client Secrets (basic/post) für höhere Sicherheit.
Refresh Tokens mit Rotation.
Revocation-Endpoint für Logout & Token-Invalidierung.

Wünsche oder besondere Anforderungen? Sag uns, was dein Team braucht.

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.

Integration ansehen Admin Login