[DRIVERS-2615] OIDC reauth sends commands we know will fail Created: 27/Apr/23  Updated: 21/Sep/23

Status: Backlog
Project: Drivers
Component/s: Authentication
Fix Version/s: None

Type: Improvement Priority: Unknown
Reporter: Maxim Katcharov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on DRIVERS-2415 Implement OIDC SASL mechanism Implementing
Driver Changes: Needed

 Description   

Summary

In the OIDC spec, to prevent unintentional expiry of a valid cache, we introduced a mechanism that allows us to check if a connection "has" an expired Access Token. Using this mechanism, we can, in a non-blocking way, check if a command will fail prior to sending it. The spec requires error-handling logic around the "sending of the command", to retry the command after reauth if the command fails (due to that expired Access Token). A pre-emptive check can be placed prior to sending the command, instead of sending the command and waiting for it to fail, and then re-sending.

Without this pre-emptive check, every time an Access Token expires, all connections will unnecessarily fail their next command (and then retry and succeed).  

Motivation

Who is the affected end user?

OIDC users.

How does this affect the end user?

Unnecessary command failures. Spec elsewhere makes effort to avoid excess round-trips (speculative auth, etc.).

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

Main path.

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

Perf concern.

Is this issue urgent?

Ideally addressed as part of original OIDC work, since it appears to be a trivial fix (few lines of code).

Is this ticket required by a downstream team?

-

Is this ticket only for tests?

not tests

Acceptance Criteria

Spec contains wording equivalent to: "Drivers must perform a pre-emptive, non-blocking check to see if the Connection's Access Token is expired. If it is, they must reauthenticate prior to performing the operation, rather than only after the operation has failed due to a 391." (The spec must still require reauth after a 391, since the token can expire on the server without the driver yet knowing.) Spec has a test that exercises the above.



 Comments   
Comment by Steve Silvester [ 21/Sep/23 ]

In DRIVERS-2616 we are removing the global cache and the drivers are no longer using the token expiration time, so I think we can close this ticket.

Generated at Thu Feb 08 08:26:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.