Allow configuring max age and expiry notifications for login tokens

[herglotzmarco]

• Trying to enforce maximum security, access tokens should not be valid forever.
• It is possible to implement automatic token rotation by directly accessing the REST service similar to what the UI does.
• Enabling max token age invalidation (which is optional and off by default for backwards compatibility) means a lot more invalidation happen.
• To help users troubleshoot 401 errors when contacting nexus, a possibility to notify users via email when their tokens expire was introduced.
• This is entirely optional and will only work if Nexus has a mail server configured via default Sonatype means.
• Leveraging OAuth2 Proxys behaviour and correct reverse proxy configuration, this allows to use API tokens like OIDC access tokens with very limited lifespan, where renewing the API token requires full OIDC login, potentially including 2FA, Passkeys or whatever login method is configured.
• If everything is configured correctly, it is not possible to renew the API token with an existing API token, but only with full OAuth2 Proxy login, further strengthening security

[tumbl3w33d]

The first 5 bullet points look good to me. I didn't wait for the time to pass but from looking at the code I'd say it's fine.

The other two

• Leveraging OAuth2 Proxys behaviour and correct reverse proxy configuration, this allows to use API tokens like OIDC access tokens with very limited lifespan, where renewing the API token requires full OIDC login, potentially including 2FA, Passkeys or whatever login method is configured.

• If everything is configured correctly, it is not possible to renew the API token with an existing API token, but only with full OAuth2 Proxy login, further strengthening security

I don't really understand or maybe I'm just over-interpreting. Nothing changed about what tokens are accepted by the realm, so you cannot just send a Bearer token to OAuth2 Proxy instead of using the good old basic auth path to Nexus, if I didn't miss something.

Maybe you could elaborate in the README about this more secure setup yet? There's also somewhere mentioned that you should configure the invalidation task and I guess this paragraph needs an update.

P.S: yet another great enhancement by you, thanks a lot!

[herglotzmarco]

I don't really understand or maybe I'm just over-interpreting. Nothing changed about what tokens are accepted by the realm, so you cannot just send a Bearer token to OAuth2 Proxy instead of using the good old basic auth path to Nexus, if I didn't miss something.

If you configure oauth2 proxy in a certain way (there is a flag called skip-jwt-bearer-tokens) it will obsolutely accept an existing bearer token and will pass this directly to Nexus (after validating against the IDP of course). In this case it will forward the Bearer Token, as well as the headers it extracted from it. Previously the plugin rejected those requests as the token factory just did nothing as soon as a auth header was present. This behaviour changed, thats why this configuration with skip-jwt-bearer-tokens is now possible. We are using this to allow the following:

1. Login directly to the IDP with some arbitrary auth flow. Could be whatever and the result is a Bearer Token
2. Send this Bearer Token as auth header to the renew-api-token endpoint of Nexus
3. OAuth2 Proxy validates the token, extracts information from it and forwards to the Nexus endpoint, which can then in a securely authenticated way return a new token
4. This allows automatic token rotation, without relying on the fact that the previous token is still valid (which is a requirement if tokens are invalidated automatically frequently with short lifespans

Maybe you could elaborate in the README about this more secure setup yet? There's also somewhere mentioned that you should configure the invalidation task and I guess this paragraph needs an update.

Yes, I will take a look at that

[tumbl3w33d]

Thanks for the explanation and yet another great contribution!