From 774242f750e4d5b624e9f84b8161435fcb7c2a3f Mon Sep 17 00:00:00 2001
From: Eric Chiang <eric.chiang@coreos.com>
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.
-- 
GitLab