Summary

Currently the credential caching section of the MONGODB-OIDC auth spec says in multiple places that drivers should invalidate a cached OIDC access token when the server returns any error while authenticating. However, that behavior could cause the driver to invalidate cached OIDC access tokens if the server is in a bad state (e.g. shutting down). In the worst case, that may lead to the OIDC cache being effectively bypassed, leading to the driver trying to fetch a new OIDC access token for every request.

Instead, drivers should only invalidate cached OIDC access tokens if the server responds with an AuthenticationFailed error (code 18).

Other minor changes in this ticket include:

• Clarify the sleep behavior for callbacks
• Clarify the use of "continues", and should also change the logic to use explicit looping (to avoid the example of 20 redundant invocations of a callback when a token expires across 21 connections).
• The OIDC callback API is overly prescriptive of the values of expiresIn. Drivers devs should be able to pick an idiomatic API as long as it's consistent with the behavior of timeoutMS (CSOT).
• There is no spec or prose test that asserts that ALLOWED_HOSTS cannot be specified in the connection string.
• Make clientId OIDC IdP configuration field optional
• Update the username portion to denote that it's optional for OIDC

Motivation

Who is the affected end user?

Users who use MONGODB-OIDC to authenticate.

How does this affect the end user?

The driver will consider the cached OIDC access token invalid, and try to fetch a new access token. Depending on the application, environment, and OIDC configuration, users may encounter various problems, including:

• The driver may hit an OIDC provider rate limit, leading to unexpected errors while running operations.
• Users may incur additional OIDC provider costs.
• For applications using the human authentication flow, end users may encounter additional unnecessary authorization prompts (e.g. a web browser pop-up asking for authorization to use the application).

How likely is it that this problem or use case will occur?

A driver would have to try to authenticate a new connection on a server that is in a bad state (e.g. shutting down) but is not marked as Unknown in the driver. That is unlikely in a running, steady-state application. It may be more likely on initial startup, so it could impact short-running applications (e.g. mongosh) or FaaS environments more.

If the problem does occur, what are the consequences and how severe are they?

The consequences are intermittent unexpected operation errors, increased costs, or a bad end-user experience.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

• Amend the MONGODB-OIDC auth spec to require that drivers only invalidate cached OIDC access tokens when the server returns error code 18.