[OIDC] Pass expired token to human OIDC callback

XMLWordPrintableJSON

    • Type: Spec Change
    • Resolution: Gone away
    • Priority: Unknown
    • None
    • Component/s: Authentication
    • None
    • Not Needed

      Summary

      Drivers should pass the expired token to the OIDC (human?) callback if it encounters a 391 reauthentication request, so that the callback's caching logic, if any, knows that the token is invalid now.

      Motivation

      Who is the affected end user?

      OIDC callback implementers, possibly only human ones.

      How does this affect the end user?

      If the cached token is not properly evicted, their connection will break.

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

      Edge case. Normally callbacks should not be passing tokens to the driver that are cached but unusable.

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

      Outage specific to the application instance in question.

      Is this issue urgent?

      This would help solve specific customer cases.

      Is this ticket required by a downstream team?

      Yes. Compass/mongosh performs caching of tokens in a way that specifically enables using the same callback for multiple MongoClient instances. If a token is accepted as valid by Compass/mongosh but rejected by the server, Compass/mongosh should still evict that token.

      The specific instance in which this behavior was observed as problematic is one in which the client application improperly assumed that ID tokens and access tokens in the same token set would both have the expiry time stated in the token set response, which is not necessarily correct. Fixing that assumption is a separate task (MONGOSH-2145), but having a way to reliably evict tokens if the MongoDB endpoint rejected them would have prevented this particular issue on a more fundamental level that would also protect against other bugs.

      There is at least one other customer case in which introducing this behavior would likely have helped avoid issues around token refreshes.

      Is this ticket only for tests?

      This is a functional change request.

      Acceptance Criteria

      Either both the machine callback and human callback or only the human callback should receive the specific access token that was rejected, or otherwise have some way to reference which previous call of the callback returned a token that was rejected by the server as expired.

            Assignee:
            Unassigned
            Reporter:
            Anna Henningsen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: