Gehostetes Login (Universal Login)

Das Problem: Wo sollte das Login-Formular wohnen?

Jede Anwendung, die Benutzer authentifiziert, muss entscheiden, wo das Login-Formular wohnt. Es gibt drei grundlegende Ansätze, und die Wahl hat tiefgreifende Sicherheitsauswirkungen.

Eingebettetes Login (der riskante Ansatz)

Die Anwendung rendert ihr eigenes Login-Formular und sammelt Anmeldedaten direkt:

Die Anmeldedaten werden an einem anderen Ursprung eingegeben — einem, der vollständig vom Identity Provider kontrolliert wird. Das JavaScript deiner Anwendung kann die Formularfelder nicht lesen, Tastenanschläge nicht abfangen oder auf die Anmeldedaten nicht zugreifen. Die Same-Origin-Richtlinie des Browsers erzwingt diese Grenze automatisch.

Funktionsweise: Der vollständige Flow

Auris Hosted Login implementiert den OAuth2-Autorisierungscode-Flow mit PKCE (RFC 7636). Hier ist die vollständige Sequenz, Schritt für Schritt.

Sequenzdiagramm

PKCE S256: Warum es wichtig ist

PKCE (Proof Key for Code Exchange) verhindert Autorisierungscode-Abfangangriffe. Der Mechanismus ist einfach, aber effektiv.

Code Verifier und Code Challenge

Bevor der Flow eingeleitet wird, generiert der Client zwei Werte:

1. Code Verifier: Ein kryptografisch zufälliger String (43-128 Zeichen)
2. Code Challenge: BASE64URL(SHA256(code_verifier))

Der Client sendet den Code Challenge (den Hash) an den Autorisierungs-Endpunkt. Beim Austausch des Codes gegen Tokens sendet der Client den rohen Code Verifier. Auris berechnet SHA256(code_verifier) neu und überprüft, ob er mit dem gespeicherten Code Challenge übereinstimmt.

code_verifier:  "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
                           │
                     SHA-256 + Base64URL
                           │
                           ▼
code_challenge: "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"

Warum dies Abfangen stoppt

Wenn ein Angreifer den Autorisierungscode in der Weiterleitungs-URL abfängt (über eine bösartige App, die im gleichen URI-Schema registriert ist, einen Proxy oder den Browser-Verlauf), können sie ihn nicht austauschen. Um den Code auszutauschen, benötigen sie den code_verifier — der nie durch die Browser-URL übertragen wurde. Er wurde im Speicher des Clients gespeichert und nur direkt über HTTPS an den Token-Endpunkt gesendet.

SHA-256 ist eine Einwegfunktion: Ausgehend vom Code Challenge kann der Angreifer ihn nicht umkehren, um den Code Verifier zu erhalten.

Sitzungsverwaltung

Auris verwendet zwei serverseitige Modelle zur Verwaltung des gehosteten Login-Flows:

OAuthSession

Wird in Schritt 3 erstellt, wenn der Benutzer am Autorisierungs-Endpunkt ankommt. Wird in der Datenbank gespeichert und durch ein httpOnly-Cookie identifiziert.

Die OAuthSession verfolgt den Fortschritt des Benutzers durch die gehosteten Login-Seiten. Sie bleibt über die Login-Seite, die 2FA-Seite (falls ausgelöst) und alle Social-Login-Weiterleitungen hinweg bestehen. Wenn der Benutzer den Flow abbricht, läuft die Sitzung ab und wird durch einen Cron-Job bereinigt.

AuthorizationCode

Wird in Schritt 9 nach erfolgreicher Authentifizierung erstellt.

Der Autorisierungscode wird über eine atomare Prisma-Transaktion verbraucht: Der Code wird als verwendet markiert und in derselben Datenbankoperation gelöscht. Wenn zwei Anfragen versuchen, denselben Code gleichzeitig zu verwenden, gelingt nur eine — die andere erhält einen Fehler.

// Atomare Einmaligkeits-Durchsetzung (vereinfacht)
const code = await prisma.authorizationCode.update({
  where: {
    code: authCode,
    usedAt: null,  // Gelingt nur, wenn noch nicht verwendet
  },
  data: {
    usedAt: new Date(),
  },
})
// Wenn der Code bereits verwendet wurde, wirft Prisma (Datensatz nicht mit usedAt: null gefunden)

Tenant-Branding

Die gehosteten Auris-Login-Seiten passen sich automatisch an die Branding-Konfiguration des Tenants an. Tenants konfigurieren Branding in der Auris-Konsole unter Einstellungen > Branding.

Die gehosteten Login-Seiten lesen Branding aus dem HostedAuthContext, der aus der Kette clientId der OAuthSession → Anwendung → Tenant aufgelöst wird:

Das Branding wird rein mit CSS-Custom-Properties angewendet, sodass die gehosteten Seiten unabhängig vom Farbschema des Tenants korrekt gerendert werden. Die Konsole enthält eine Live-Vorschau, damit Administratoren die Auswirkungen vor der Veröffentlichung sehen können.

Die Sicherheitspipeline

Jeder Authentifizierungsversuch über das gehostete Login durchläuft die vollständige Auris-Sicherheitspipeline. Keine Schicht kann umgangen werden — sie werden sequenziell ausgeführt, und jede Schicht kann die Anfrage blockieren.

Jede Schicht ist unabhängig pro Tenant konfigurierbar. Ein kleines Startup hat möglicherweise nur Keycloak-Auth aktiviert, während ein Enterprise-Tenant alle neun Schichten aktiv haben könnte.

Social Login auf gehosteten Seiten

Auris unterstützt 9 Social-Login-Provider auf den gehosteten Login-Seiten:

Wenn ein Tenant Social-Provider in der Konsole aktiviert, zeigt die gehostete Login-Seite automatisch die entsprechenden Schaltflächen an. In der Client-Anwendung sind keine Änderungen erforderlich — Social Login wird vollständig innerhalb der gehosteten Seite behandelt.

SSO-Erkennung über E-Mail-Domain

Für Tenants mit konfiguriertem Enterprise SSO (SAML 2.0 / OIDC-Federation) kann die gehostete Login-Seite SSO-Domains automatisch erkennen. Wenn der Benutzer seine E-Mail-Adresse eingibt:

1. Die Seite ruft GET /api/auth/sso/[email protected] auf
2. Wenn die Domain company.com verifiziert und mit einer SSO-Verbindung verknüpft ist, zeigt die Seite eine Schaltfläche „Mit SSO fortfahren” an
3. Ein Klick darauf leitet durch den SSO-Flow (Keycloak IdP-Brokering) anstelle der Passwort-Authentifizierung weiter

Dies bietet eine nahtlose Erfahrung: Benutzer von SSO-fähigen Organisationen werden automatisch zu ihrem Unternehmens-Identity-Provider weitergeleitet.

Vergleich: Login-Ansätze

Code-Beispiel: Verwendung des Auris SDK

Der empfohlene Weg zur Integration des gehosteten Logins ist über das Auris SDK. Das SDK übernimmt PKCE-Generierung, State-Verwaltung, Weiterleitungsbehandlung und Token-Speicherung automatisch.

JavaScript SDK (@auris/js)

import { AurisClient } from '@auris/js'
 
const auris = new AurisClient({
  domain: 'your-tenant.auris.example.com',
  clientId: 'app_abc123',
  redirectUri: 'https://app.ihredomain.com/callback',
  autoRefresh: true,
})
 
// Login einleiten — leitet zur gehosteten Login-Seite weiter
// Intern: generiert code_verifier, berechnet S256-Challenge,
// generiert State, speichert beides in sessionStorage, leitet weiter
await auris.loginWithRedirect()
 
// Auf der Callback-Seite (/callback) — Code gegen Tokens austauschen
// Intern: validiert State, extrahiert Code aus URL,
// sendet Code + code_verifier an Token-Endpunkt, speichert Tokens
const result = await auris.handleRedirectCallback()
 
console.log(result.user)
// {
//   id: 'usr_abc123',
//   email: '[email protected]',
//   firstName: 'Jane',
//   lastName: 'Doe',
//   roles: ['user'],
// }

React SDK (@auris/react)

import { AurisProvider, useAuris, AuthGuard } from '@auris/react'
 
// Deine App mit AurisProvider umhüllen
function App() {
  return (
    <AurisProvider
      domain="your-tenant.auris.example.com"
      clientId="app_abc123"
      redirectUri="https://app.ihredomain.com/callback"
    >
      <Router />
    </AurisProvider>
  )
}
 
// Den Hook in einer beliebigen Komponente verwenden
function LoginButton() {
  const { loginWithRedirect, isAuthenticated, user, logout } = useAuris()
 
  if (isAuthenticated) {
    return (
      <div>
        <span>Willkommen, {user.firstName}</span>
        <button onClick={() => logout()}>Abmelden</button>
      </div>
    )
  }
 
  return <button onClick={() => loginWithRedirect()}>Anmelden</button>
}
 
// Routen mit AuthGuard schützen
function ProtectedPage() {
  return (
    <AuthGuard>
      <Dashboard />
    </AuthGuard>
  )
}

Next.js SDK (@auris/nextjs)

// middleware.ts — Routen am Edge schützen
import { aurisMiddleware } from '@auris/nextjs'
 
export default aurisMiddleware({
  protectedPaths: ['/dashboard', '/settings', '/admin'],
  publicPaths: ['/', '/about', '/pricing'],
  loginPath: '/auth/login',
})
 
export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

// Server Component — Auth auf dem Server prüfen
import { getSession } from '@auris/nextjs/server'
 
export default async function DashboardPage() {
  const session = await getSession()
 
  if (!session) {
    redirect('/auth/login')
  }
 
  return <h1>Willkommen, {session.user.firstName}</h1>
}

Weiterleitungs-URI-Validierung

Auris erzwingt eine strikte Weiterleitungs-URI-Validierung, um den Diebstahl von Autorisierungscodes über Open-Redirect-Angriffe zu verhindern.

Regeln

Wenn die redirect_uri nicht mit einem registrierten Wert übereinstimmt, gibt Auris eine Fehlerseite direkt zurück (es leitet nicht zur nicht übereinstimmenden URI weiter, da dies den Zweck zunichte machen würde).

Warum exakte Übereinstimmung?

Partielle Übereinstimmung (z. B. Präfix-Übereinstimmung wie https://app.example.com/) schafft eine Schwachstelle: Ein Angreifer könnte https://app.example.com/evil-page registrieren und Autorisierungscodes dorthin leiten lassen. Exakte Übereinstimmung eliminiert diese Angriffskategorie vollständig.

Bereinigung und Ablauf

Auris führt einen Cron-Job (/api/oauth/cron/cleanup/) zur Bereinigung abgelaufener Sitzungen und Codes aus:

Der Cron läuft periodisch (konfiguriert in vercel.json) und stellt sicher, dass die Datenbank keine veralteten Sitzungen aus abgebrochenen Login-Flows ansammelt.

Verwandte Konzepte

• PKCE-Flow — Detaillierte Anleitung zum PKCE-Mechanismus, der vom gehosteten Login verwendet wird
• OAuth 2.0 & OIDC — Das Autorisierungs-Framework, das das gehostete Login implementiert
• Sitzungen & Token-Rotation — Wie Tokens nach dem gehosteten Login verwaltet werden
• Adaptives MFA & Risikobewertung — Risikobasiertes Step-up-MFA während des Login-Flows
• Actions & Sandbox-Ausführung — Benutzerdefinierte Logik-Hooks, die während des gehosteten Logins ausgeführt werden
• Tokens erklärt — Die Zugriffs-, Refresh- und ID-Tokens, die nach dem Login zurückgegeben werden