Known Limitations

Parallel Refresh Token Grants

Requests originating from the same user/session reaching different Apache processes simultaneously may lead to execution of several refresh token grants in parallel which could lead to issuance of overlapping/invalidated refresh tokens when used with rolling refresh tokens. Mitigations have been added in 2.4.15 to avoid this at least on a single Apache server using a global system lock.

When rolling refresh tokens are used across different Apache processes, a "best effort distributed parallel refresh prevention" mechanism can be enabled with the environment variable OIDC_PARALLEL_REFRESH_NOT_ALLOWED (i.e. SetEnvIfExpr true OIDC_PARALLEL_REFRESH_NOT_ALLOWED=true) since 2.4.15. This pushes a "best effort" lock to the shared cache for the duration of OIDCHTTPTimeoutLong. When another refresh request is initiated with the same refresh token during that time, a HTTP 500 will be returned. Note that this is not failsafe, so the advice is still to not use rolling refresh tokens with multiple Apache instances.

POST Data Preservation (1)

Preservation of POST data with OIDCPreservePost On over session timeouts and newly initiated sessions is only supported with simple name/value pairs i.e. using Content-Type: application/x-www-form-urlencoded, not arbitrary (streamed) POST data.

POST Data Preservation (2) and Authorization / Step-Up Authentication

Preservation of POST date combined with OIDCPreservePost On and Authorization using Require claim directives or Step-Up Authentication don't work together over plain HTTP, running over HTTPs does seem to avoid this limitation. See also other limitations associated with Step-Up Authentication here: https://github.com/OpenIDC/mod_auth_openidc/wiki/Step-up-Authentication#limitations

Global Provider Configuration

It is not possible to specify OpenID Connect Provider primitives (OIDCProvider*) on a on a per-directory/location basis, those primitives are only supported on the global/vhost level.