Parameter:
OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDSShort description: Enables specific workarounds for Microsoft Azure AD B2C as an OIDC provider — in particular the
client_id is additionally sent as a requested scope, which Azure AD B2C strictly requires (in conflict with the OIDC specification). Default: disabled (0).Profile
Parameter | OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS |
Category | Security / TLS (OIDC / Web SSO / Azure AD B2C) |
Component | Server (HTTP task) |
Available since | 14.0 |
Supported versions | 14.0, 14.5, 14.5.1 |
GUI equivalent | notes.ini only (no GUI) |
Possible values | 0 = OIDC-spec-compliant behavior (default) 1 = Azure AD B2C workaround active (send client_id as scope) |
Description
Microsoft Azure AD B2C (the business-to-consumer variant of Azure AD for external users such as customers, citizens, or partners) requires, for historical implementation reasons, that the
client_id be sent as an additional requested scope — for example scope=openid email profile <client_id>. This behavior is not spec-compliant (the OIDC spec defines client_id as a separate parameter, not as a scope), but Azure AD B2C flatly rejects token requests without this "extra scope".With
OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=1, Domino automatically appends the client_id as an additional scope to the authorization request, which makes the login flow against Azure AD B2C work.Clear distinction:
- Azure AD (regular, for employee logins) — does NOT need this workaround. Standard OIDC is sufficient.
- Azure AD B2C (consumer variant) — requires this workaround.
Set to 1 when:
- The configured OIDC provider is an Azure AD B2C tenant URL (typical format:
https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/<policy>/v2.0/).
- The symptom occurs: login fails with provider error
AADB2C90205: This application does not have sufficient permissionsorinvalid_request: The request is missing a required scope.
Example configuration
OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=1
Notes & pitfalls
- Default is
=0— only set to 1 explicitly if Azure AD B2C is used as the provider.
- Do not confuse with regular Azure AD: Azure AD (employees, M365 tenant) does not need this workaround. If enabled there, Azure AD rejects the unknown scope.
- For Azure AD B2C, also note: custom policies often define their own claim structures —
OIDC_LOGIN_CUSTOM_CLAIM_NAMEmay also be required to select the correct identifier (e.g.oid,emails).
- Highly recommended: test with
DEBUG_OIDCLogin=4— the console shows the full authorization request including the scope list.
- Prerequisite: HTTP Bearer Authentication and Web login with OIDC are enabled in the relevant Internet Site document.
- Change takes effect after a restart of the HTTP task or via
set config OIDC_LOGIN_ENABLE_AZURE_AD_B2C_WORKAROUNDS=….
- Works only on Windows and Linux servers.
- For Azure AD B2C: check the app registration manifest in the provider tenant — redirect URIs must contain exactly the Domino URLs
/auth/protocol/oidc.
Sources (HCL Product Documentation)
- HCL Domino 14.5.1 – Configuring OIDC-based SSO for web users: help.hcl-software.com/domino/14.5.1/admin/secu_config_oidc_based_sso_for_web.html