CLI credentials' JWT returns 403 after server restart and before OAuth flow triggered

[JanekLehr]

Problem

After nexus-proxy is restarted all JWTs obtained from /cli/credentials result in 403 responses, and the server logs claim it's because the principal "is not an organization member. Denying". Once a user has renewed their session by navigating to the browser and completing the OAuth flow, then the cli credential JWT authorizes successfully.

This is related to #3, which was closed but I found it to still be a problem.

Reason

The principal is extracted from the JWT and then a credential store of previously authenticated OAuth tokens is checked for a matching principal. If no match is found then the principal is not considered an organization member. The JWT is stored by clients and the credential store is stored on the server, but currently that store is in memory only.

The credential store is wiped out when the server restarts because it lives in memory only. Therefore there is no matching token for the principal contained in the JWT provided by the client. Sessions are lost too, so when users navigate to the nexus-proxy they are forced to go through the OAuth flow again. When that happens, a new token is put into the credential store and subsequent calls with the previous JWT now have principal matches.

Since this proxy is primarily used in Kubernetes deployments, this loss of JWT validity becomes a problem every time there is an update of the Nexus pod or a pod gets rescheduled for planned and unplanned reasons.

[pires]

Could you please check if setting JWT_REQUIRES_MEMBERSHIP_VERIFICATION to true in your deployment fixes this issue for you?

[pires]

Sorry, I meant false. I could've edited the comment but not sure if you've read it already so here's a new comment for calling your attention to that fact.

[JanekLehr]

@pires The problem is that I do need it to verify membership each time.