add explanation for oidc refresh token issue #1808
Conversation
kubermatic-bot
added
dco-signoff: yes
* adding explanation on the known issue * adding a way to configure dex to handle multiple refresh tokens per user/client ** adding explanation on security considerations Signed-off-by: soer3n <[email protected]>
soer3n
force-pushed
the
add-oidc-refresh-token-info-to-known-issues
branch
from
7291351 to
088d438
Compare
| You can either change this in dex helm values by setting `userIDKey` to `jti` and `userNameKey` for example to `email` in the config section of a connector or you could configure an other oidc provider which supports multiple refresh tokens per user-client pair like keycloak does by default. | ||
|
|
There was a problem hiding this comment.
Please provide an example config in yaml format as well
There was a problem hiding this comment.
Spliited the solution section into dex and external provider and added an example connector snippet for dex.
| With the default helm chart values for dex it is only possible to have one refresh token per user/client pair for security reasons. The refresh token has by default also no expiration set. This is useful to stay logged in over a longer time because the id_token can be refreshed unless the refresh token is invalidated. | ||
|
|
There was a problem hiding this comment.
With the default helm chart values for dex
It's a limitation in dex, not the helm chart of dex so i'd avoid mentioning helm chart here.
There was a problem hiding this comment.
Changed wording to dex configuration instead of helm values.
|
|
||
| ### Root Cause | ||
|
|
||
| With the default helm chart values for dex it is only possible to have one refresh token per user/client pair for security reasons. The refresh token has by default also no expiration set. This is useful to stay logged in over a longer time because the id_token can be refreshed unless the refresh token is invalidated. |
There was a problem hiding this comment.
Please add link to the upstream issues for dex
|
|
||
| ### Problem | ||
|
|
||
| One example would be to download a kubeconfig of one cluster and then of another with the same user. You should only be able to use the first kubeconfig until the id_token expires because the refresh token was already invalidated by the download of the second one. This happens when a new one was requested. |
There was a problem hiding this comment.
The wording needs to be improved a bit, i'd also suggest first mentioning the issue and then giving an example.
There was a problem hiding this comment.
I moved the example to the root cause section and generalized the explanation in the problem section.
|
|
||
| You can either change this in dex helm values by setting `userIDKey` to `jti` and `userNameKey` for example to `email` in the config section of a connector or you could configure an other oidc provider which supports multiple refresh tokens per user-client pair like keycloak does by default. | ||
|
|
||
| For dex this has some implications. With this configuration a token is generated for each user session. The number of objects stored in kubernetes regarding refresh tokens has no limit anymore. The principle that one refresh belongs to one user/client pair is a security consideration which would be ignored in that case. The only way to revoke a refresh token is then to do it via grpc api which is not exposed by default or by manually deleting the related refreshtoken resource in the kubernetes cluster. |
There was a problem hiding this comment.
Maybe this can have it's own heading since this section(known limitations or similar) is quite important; this needs more visibility.
There was a problem hiding this comment.
Thanks for the hint. I added another section for it.
kubermatic-bot
added
size/L
soer3n
force-pushed
the
add-oidc-refresh-token-info-to-known-issues
branch
from
6ca77ba to
e3779c2
Compare
* add an example yaml for connector configuration * move implications of the dex solution to an own heading * reword problem description * move example explanation to root cause section Signed-off-by: soer3n <[email protected]>
soer3n
force-pushed
the
add-oidc-refresh-token-info-to-known-issues
branch
from
e3779c2 to
ae7b671
Compare
|
LGTM label has been added. Git tree hash: e82c9de0fc02c1969d49a93071be2869e85ff5f1
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahmedwaleedmalik The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubermatic-bot
added
the
approved
This pr adds information about a problem regarding oidc authentication on kkp usercluster observed in kubermatic/kubermatic#13573 to known issues.