Start/notes.ini Parameter/OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS

OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS

Steckbrief

Parameter
OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS
Kategorie
Security / TLS (OIDC / Web-SSO / Azure AD B2C)
Komponente
Server (HTTP-Task)
Verfügbar seit
14.0
Unterstützte Versionen
14.0, 14.5, 14.5.1
GUI-Entsprechung
Nur notes.ini (keine GUI)
Mögliche Werte
0 = OIDC-spezifikations­konformes Verhalten (Standard)
1 = Azure-AD-B2C-Workaround aktiv (client_id als Scope mitsenden)

Beschreibung

Microsoft Azure AD B2C (Business-to-Consumer-Variante von Azure AD für externe User wie Kunden, Bürger, Partner) verlangt aus historischen Implementierungs­gründen, dass die client_id als zusätzlicher Scope mit angefordert wird — also z. B. scope=openid email profile <client_id>. Dieses Verhalten ist nicht spezifikations­konform (die OIDC-Spec definiert die client_id als separaten Parameter, nicht als Scope), aber Azure AD B2C lehnt Token-Requests ohne diesen „Extra-Scope" rundweg ab.
Mit OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=1 hängt Domino automatisch die client_id als zusätzlichen Scope an den Authorization-Request an, was den Login-Flow gegen Azure AD B2C zum Funktionieren bringt.
Klare Abgrenzung:
  • Azure AD (regulär, für Mitarbeiter-Logins) — benötigt diesen Workaround NICHT. Standard-OIDC reicht.
  • Azure AD B2C (Consumer-Variante) — benötigt diesen Workaround zwingend.
Auf 1 setzen, wenn:
  • Der konfigurierte OIDC-Provider eine Azure-AD-B2C-Tenant-URL ist (typisches Format: https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/<policy>/v2.0/).
  • Das Symptom auftritt: Login schlägt mit Provider-Fehler AADB2C90205: This application does not have sufficient permissions oder invalid_request: The request is missing a required scope fehl.

Beispiel-Konfiguration

OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=1

Hinweise & Stolperfallen

  • Standard ist =0 — nur explizit auf 1 setzen, wenn Azure AD B2C als Provider verwendet wird.
  • Nicht mit regulärem Azure AD verwechseln: Azure AD (Mitarbeiter, M365-Tenant) braucht den Workaround nicht. Falls man ihn dort aktiviert, lehnt Azure AD den unbekannten Scope ab.
  • Bei Azure AD B2C zusätzlich beachten: Custom-Policies definieren oft eigene Claims-Strukturen — ggf. ist OIDC_LOGIN_CUSTOM_CLAIM_NAME nötig, um den richtigen Identifier (z. B. oid, emails) auszuwählen.
  • Sehr empfehlenswert: Mit DEBUG_OIDCLogin=4 testen — die Konsole zeigt den vollständigen Authorization-Request inkl. Scope-Liste.
  • Voraussetzung: HTTP Bearer Authentication und Web-Login mit OIDC sind im betreffenden Internet Site-Dokument aktiviert.
  • Änderung wirkt nach Neustart des HTTP-Tasks bzw. via set config OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=….
  • Funktioniert nur auf Windows- und Linux-Servern.
  • Bei Azure AD B2C: Im Provider-Tenant das App-Registrierungs-Manifest prüfen — Redirect-URIs müssen exakt die Domino-URLs /auth/protocol/oidc enthalten.

Quellen (HCL Product Documentation)