Authentifizierung

ObjectOS verwendet das ObjectStack-Authentifizierungs-Plugin, das auf Better Auth basiert. Die Authentifizierung ist projektlokal: Jedes Projekt hat seine eigenen Identitätstabellen und seinen eigenen Sitzungsbereich.

Was wird unterstützt

Abhängig von der paketierten Anwendung und den aktivierten Einstellungen kann ObjectOS Folgendes unterstützen:

• Anmeldung per E-Mail/Passwort;
• Sitzungsverwaltung;
• Passwortzurücksetzung und E-Mail-Verifizierung;
• soziale OAuth-Anbieter wie Google, GitHub, Microsoft und Apple;
• Enterprise-OIDC/SSO wie Okta, Entra ID, Keycloak und Ping;
• Zwei-Faktor-Authentifizierung;
• Passkeys/WebAuthn;
• Magic Links;
• CLI-/Browser-Device-Flow.

Erforderliches Geheimnis

Legen Sie fest:

OS_AUTH_SECRET=replace-with-a-strong-random-secret

ObjectOS leitet aus diesem Wert und der Projektumgebungs-ID ein stabiles projektspezifisches Geheimnis ab. Das bedeutet:

• Sitzungen überstehen Container-Neustarts;
• Tokens aus einem Projekt können nicht in einem anderen Projekt wiederverwendet werden;
• das Rotieren von OS_AUTH_SECRET macht Sitzungen ungültig.

Siehe Environment variables für die vollständige Liste der authentifizierungsbezogenen Einstellungen, einschließlich des veralteten AUTH_SECRET-Alias.

Sitzungsisolierung

In Bereitstellungen mit mehreren Projekten sind Cookies auf den Projekt-Hostnamen beschränkt. ObjectOS vermeidet bewusst weitreichende Root-Domain-Cookies für Projektsitzungen. Dadurch wird verhindert, dass eine Sitzung über Kundenprojekte hinweg durchsickert.

Soziale Anmeldung

Konfigurieren Sie die Anbieter-Anmeldedaten über Umgebungsvariablen oder Systemeinstellungen, je nachdem, wie das Anwendungspaket die Authentifizierungskonfiguration bereitstellt.

Die Callback-URLs der Anbieter hängen vom Anbietertyp ab. ObjectStack stellt zwei unterschiedliche Callback-Pfade bereit, die nicht austauschbar sind:

Beispiele:

https://crm.example.com/api/v1/auth/callback/google
https://crm.example.com/api/v1/auth/callback/microsoft
https://crm.example.com/api/v1/auth/oauth2/callback/okta
https://crm.example.com/api/v1/auth/oauth2/callback/entra

Konfigurieren Sie die passende Redirect-URI in der Anwendungsregistrierung des Identitätsanbieters, bevor Sie den Anbieter in ObjectOS aktivieren.

Enterprise-OIDC/SSO

OIDC-Anbieter werden als generische OAuth2-Anbieter registriert und verwenden den Pfad /api/v1/auth/oauth2/callback/<provider>. Eine typische Konfiguration erfordert:

Bevorzugen Sie für Kundenbereitstellungen OIDC-Discovery-URLs gegenüber manuell konfigurierten Authorization-/Token-/Userinfo-Endpunkten.

Plattform-SSO

In cloud-verbundenen Bereitstellungen kann ObjectOS die Control-Plane-Anmeldung als Plattform-SSO-Anbieter verwenden. Ein Builder, der bereits an der Control Plane angemeldet ist, kann in eine Projektlaufzeit bereitgestellt werden, ohne ein separates projektlokales Konto zu erstellen.

Dies erfordert, dass die Control Plane und ObjectOS dasselbe OS_AUTH_SECRET-Basisgeheimnis teilen. Deaktivieren Sie Plattform-SSO nur, wenn der Kunde möchte, dass jedes Projekt eine vollständig separate Anmeldegrenze besitzt.

Betriebsprüfungen

Vor der Produktion:

• bestätigen Sie, dass abgelaufene Tokens 401 zurückgeben;
• bestätigen Sie, dass die Abmeldung die aktive Sitzung widerruft;
• bestätigen Sie, dass die Passwortzurücksetzung andere Sitzungen widerruft, falls die Richtlinie dies erfordert;
• bestätigen Sie, dass die Callback-URLs mit der öffentlichen Projektdomäne übereinstimmen;
• bestätigen Sie, dass vertrauenswürdige Ursprünge nur genehmigte Domänen enthalten;
• bestätigen Sie, dass OS_AUTH_SECRET in einem Secret Manager gespeichert ist und nicht im Quellcode.

Nächste Schritte

Die Authentifizierung legt fest, wer ein Benutzer ist. Um zu steuern, worauf ein Benutzer nach der Anmeldung zugreifen kann, siehe Permissions. Für Nicht-Browser-Clients und Machine-to-Machine-Zugriff siehe API access.