Start/notes.ini Parameters/OIDC_LOGIN_RESPONSE_MODE_FORM_POST

OIDC_LOGIN_RESPONSE_MODE_FORM_POST

Profile

Parameter
OIDC_LOGIN_RESPONSE_MODE_FORM_POST
Category
Security / TLS (OIDC / Web SSO)
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 = default response_mode=query (default)
1 = request response_mode=form_post (only if the provider supports it)

Description

The OIDC response_mode parameter specifies how the provider returns the authorization code and any further parameters to the client (Domino):
  • query (default): the code is appended as a URL query parameter to the redirect: https://server/auth/protocol/oidc?code=…&state=…. Advantage: simple, broadly supported. Disadvantage: the code ends up in browser history and server logs.
  • form_post: the provider sends the response as an HTTP POST body to the redirect URI. Advantage: the code does not appear in URLs/logs — security advantage.
  • fragment: for the implicit flow — not relevant for Domino, which exclusively uses the authorization-code flow.
Domino uses query by default. With OIDC_LOGIN_RESPONSE_MODE_FORM_POST=1, form_post is requested — but only if the discovery document of the trusted OIDC provider (well-known endpoint) lists form_post as a supported mode (response_modes_supported).
Set to 1 when:
  • The OIDC provider explicitly supports and recommends form_post (e.g. Microsoft Identity Platform).
  • Security requirements forbid having codes/tokens visible in URLs.
  • Reverse-proxy or WAF logs should be suppressed.
Important: The Domino-native OIDC provider (Domino can act as an IdP itself) currently does not support form_post — when Domino-OIDC instances federate with each other, always leave at the default.

Example configuration

OIDC_LOGIN_RESPONSE_MODE_FORM_POST=1

Notes & pitfalls

  • Default is =0 — only enable if the provider lists form_post in the well-known endpoint, otherwise Domino falls back to query or the login fails.
  • Verify that the provider really supports the mode: open https://provider/.well-known/openid-configuration and read the response_modes_supported field.
  • Prerequisite: HTTP Bearer Authentication and web login with OIDC are enabled in the relevant Internet Site document.
  • With DEBUG_OIDCLogin=2, you can observe which response mode is actually negotiated.
  • If Domino itself acts as an OIDC provider (own IdP cluster): do NOT set this parameter, as the Domino provider does not deliver form_post.
  • Change takes effect after a restart of the HTTP task or via set config OIDC_LOGIN_RESPONSE_MODE_FORM_POST=….
  • Works only on Windows and Linux servers.
  • Security advantage: with form_post, the authorization code does not appear in browser history, in web-server access logs, or in Referer headers.

Sources (HCL Product Documentation)