> If it is still valid, can I force a refresh? You can force a full re-authentication involving the browser (by setting UI policy parameter to GSIGNOND_UI_POLICY_REQUEST_PASSWORD), but you can't force a refresh using a refresh token if the existing token is still valid. So the application should: - request a token and try to use it - in case of failure try to request a token again, and try to use it again (in case the first token has expired just before using it) - if the second token also fails, request a third token with full re-authentication as above. - if that fails, then give up.

Also, after giving it some thought, I think that forcing the use of refresh token can make sense in case of flaky servers or clock drift. So I'll add that capability to the plugin, and the proper sequence will look like this: - request a token and try to use it - if it's rejected, request a token again, with a flag that forces the use of refresh token - if the second token is also rejected, enable GSIGNOND_UI_POLICY_REQUEST_PASSWORD and try for the last time.

On 07/30/2013 06:46 PM, Patrick Ohly wrote: >> Also, after giving it some thought, I think that forcing the use of >> refresh token can make sense in case of flaky servers or clock drift. So >> I'll add that capability to the plugin, and the proper sequence will >> look like this: >> >> - request a token and try to use it >> - if it's rejected, request a token again, with a flag that forces the >> use of refresh token >> - if the second token is also rejected, enable >> GSIGNOND_UI_POLICY_REQUEST_PASSWORD and try for the last time. > > I agree, forcing refresh makes sense. > > I just noticed that we didn't have Alberto on this part of the mail > thread. Adding him back. So I've done and pushed all the updates to the OAuth plugin that we agreed on: - support for Google's login_hint (set 'UseLoginHint' to TRUE)

- support for forced use of refresh token (set 'ForceTokenRefresh' to TRUE) - support for caching tokens according to scope (this is transparent, but you need to create a new identity because the format of the token cache has changed). You should be able to remove the workaround of using several client IDs in SyncEvo now.

> > - support for Google's login_hint (set 'UseLoginHint' to TRUE) > > I don't remember what that was about - can you remind me when setting > that to true will be useful? If you know the username you are trying to authenticate, then, if that username is stored in an identity, or provided to gsso when initiating an authentication session, and UseLoginHint is set to TRUE, then Google will pre-fill the email box on the sign-in form or select the proper multi-login browser session, so the app authorization flow is simpler for the user. It's a non-standard google extension, so not enabled by default.

On 08/05/2013 09:16 PM, Patrick Ohly wrote: > Alberto, implementing 'ForceTokenRefresh' in signond would be useful. > Otherwise, when there is some clock skew and the server already rejects > the access token while the client still thinks that the token has not > expired yet, getting the token refreshed via signond will not work. > > In the meantime, is it okay to pass that key in the session data even > though signond doesn't understand it (yet)? All unknown keys are ignored, so yes, you can pass it. While I understand the reason for ForceTokenRefresh, what I don't like about it is that it complicates the client code: not only clients need to catch errors from signond, but even in the case of a successful response they must handle the case of an expired access token and re-request one. I'd propose an alternate (and simpler) solution: when we have a refresh token, avoid caching the access token.

On 08/06/2013 09:10 AM, Patrick Ohly wrote: > This assumes that a new token is always valid long enough for the client > to finish its task. I suspect that even with simple clients, this may > not always be true. For example, the client might run while a laptop > gets suspended and resume after the token that it uses expired. Always > asking for a new token before each HTTP request would also not work > reliably and without access token caching be too expensive. > > A more complex client, one which runs for extended periods of time, will > have to be aware of the need to refresh tokens anyway. I don't think so. A client should simply assume that the token it gets is valid, and use it as long as it can. As soon as some calls start to fail because the token is invalid, it would have to request a new one. If even the new token is wrong, it should use add the UiPolicy=RequestPasswordPolicy to the parameters dictionary and request a new one, and if that also fails, just stop trying.

Note that this flow is not OAuth specific, and the client doesn't need to know anything about refresh tokens.

I don't think so. A client should simply assume that the token it gets is valid, and use it as long as it can. As soon as some calls start to fail because the token is invalid, it would have to request a new one.

If even the new token is wrong, it should use add the UiPolicy=RequestPasswordPolicy to the parameters dictionary and request a new one, and if that also fails, just stop trying.

> I'd propose an alternate (and simpler) solution: when we have a > refresh token, avoid caching the access token. So every request from an app for a token would result in a roundtrip to the token endpoint, and a new access token being issued? That's abuse of refresh tokens, in my opinion.

Clients are supposed to use the tokens they've been issued for as long as they can, and one of SSO's selling points is a secure token cache.

>>> I'd propose an alternate (and simpler) solution: when we have >>> a refresh token, avoid caching the access token. >> >> So every request from an app for a token would result in a >> roundtrip to the token endpoint, and a new access token being >> issued? That's abuse of refresh tokens, in my opinion. > > Not really, given that the use of refresh tokens is not even > mandatory. > >> Clients are supposed to use the tokens they've been issued for as >> long as they can, and one of SSO's selling points is a secure >> token cache. > > Yes, but this does not contradict the above. I don't understand your response; it's too terse. Instead of keeping the access token until it stops working, you are proposing to replace it with a new one via token refresh every time it's requested by the app (and that may be fairly frequent, depending on the app's process lifecycle). That violates the idea of access tokens: you should be keeping and using the one you got for as long as possible. It also unnecessarily adds to the client's use of power and network. Also, multiply the frequent token refresh procedure by thousands (millions) of clients and servers will have a problem with it.

How about the following situation: - the access token is valid for 1 day, not for 1 hour - the app is a small helper that runs every 10 minutes and then exits (maybe it updates a facebook feed, or something similar), so it's not able to keep the access token in its process memory. Then the refreshes are 144 times more frequent than is expected. If you have shipped a lot of devices that behave like this, the service may well decide to block the client key for misbehaviour.

>> Then the refreshes are 144 times more frequent than is expected. >> If you have shipped a lot of devices that behave like this, the >> service may well decide to block the client key for >> misbehaviour. > > I never saw anything like this. Using refresh tokens is not > mandatory; of course it's possible that some server decides > otherwise, but I'd worry about that only when you point me at some > real cases. :-) You never saw what specifically, long-lasting access tokens, frequent short-lived application processes, a combination of the two, or blocking of client keys, or something else?

I don't understand the point about optional usage of refresh tokens either. What does it mean, and why is it relevant?

the lifetime of the access token, then indeed with my proposed solution we'd be generating more traffic than needed, but I don't think that's the usual case in the Linux world and in any case I don't see it as terribly wrong. In any case, after the application gets the access token, it *uses* the network to do something, so the "waste" is amortized.