Session expires based on ID Token instead of Access Token about pinniped HOT 2 CLOSED

Hi @dmeijboom, thanks for creating an issue.

I think what you are seeing is by design, although I can understand why you were hoping for a different behavior. I can try to explain and I can also propose some potential solutions.

When you use a JWTAuthenticator what you are saying is conceptually "when anyone shows up at this cluster's front door holding a JWT from the expected issuer with the expected audience claim, then allow them to authenticate as the username from the configured username claim of the JWT and group memberships from the configured groups claim of the JWT". The cluster (the Concierge, more specifically) is only presented with the ID token. It does not receive the access token nor any other information, so it has no other information to work from. That JWT must not be expired. The JWTAuthenticator code is actually borrowed from Kubernetes, and is performing the exact same checks as Kubernetes own OIDC authenticator. Also note that OIDC does not require that access tokens be JWTs, and in fact they are often opaque tokens with no way to know their lifetime by only looking at the token itself, so in general an access token would not be enough information to imply a longer lifetime all by itself anyway, which is probably one of the reasons why the Kubernetes code does not use access tokens in addition to the ID token for auth.

However, there are possible solutions.

1. If your OIDC provider issued refresh tokens, then the Pinniped CLI would notice that the ID token is expired and it would use the refresh token to attempt to get a new ID token that it could send to the cluster. This would happen without any need for user interaction, so it would feel seamless.
2. If you use the Pinniped Supervisor, then it will issue its own ID, access, and refresh tokens after the user has authenticated with your external OIDC provider. The Pinniped CLI would perform refreshes against the Supervisor using the Supervisor-issued refresh token, and during those refreshes the Supervisor would use either the external provider's refresh token (preferred) or the external provider's access token (if there was no refresh token handed out by the external provider) to make various calls to your external provider to determine if the user's session should be allowed to continue.

Either of those approaches should allow the user's session to continue longer without any user interaction.

Does that help?

from pinniped.

Thanks for the detailed reply. I wasn't aware that the JWTAuthenticator only looks at the ID token. That makes sense. Our OIDC provider should simply reply with refresh tokens, I guess that's the easiest way to move forward.

Thanks again! I'll close this issue as its exactly how pinniped should work.

from pinniped.