From 774242f750e4d5b624e9f84b8161435fcb7c2a3f Mon Sep 17 00:00:00 2001 From: Eric Chiang Date: Mon, 17 Oct 2016 11:53:46 -0700 Subject: [PATCH] Documentation/proposals: added a caveats section to upstream refreshing proposal --- .../proposals/upstream-refreshing.md | 21 ++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/Documentation/proposals/upstream-refreshing.md b/Documentation/proposals/upstream-refreshing.md index 628ae89e..019bd9f8 100644 --- a/Documentation/proposals/upstream-refreshing.md +++ b/Documentation/proposals/upstream-refreshing.md @@ -2,12 +2,12 @@ ## TL;DR -Today, if a user deletes their Google account, dex will keep allowing clients to +Today, if a user deletes their GitHub account, dex will keep allowing clients to refresh tokens on that user's behalf because dex never checks back in with -Google. +GitHub. This is a proposal to change the connector package so the dex can check back -in with Google. +in with GitHub. ## The problem @@ -148,3 +148,18 @@ func (db passwordDB) Refresh(s connector.Scopes, identity connector.Identity) (c return identity, nil } ``` + +## Caveats + +Certain providers, such as Google, will only grant a single refresh token for each +client + end user pair. The second time one's requested, no refresh token is +returned. This means refresh tokens must be stored by dex as objects on an +upstream identity rather than part of a downstream refresh even. + +Right now `ConnectorData` is too general for this since it is only stored with a +refresh token and can't be shared between sessions. This should be rethought in +combination with the [`user-object.md`](./user-object.md) proposal to see if +there are reasonable ways for us to do this. + +This isn't a problem for providers like GitHub because they return the same +refresh token every time. We don't need to track a token per client.