> > > > Consider what happens when a client web server is compromised and the > client secret and refresh tokens are stolen. > - the attacker can use the tokens until the compromise is discovered. > - the client secret is then changed > - the stolen refresh tokens then become useless > > Now, *if* the implicit grant type returns refresh token, that story > changes. Even if the client secret is changed, the attacker can keep > using the refresh tokens!
I think this is exactly the point! It only makes sense for the auth code flow where client credentials are supplied in the refresh token request. The idea behind not issuing a refresh token to a client that can't store confidential client credentials is there that is no protection against a compromised refresh token. A refresh token request requires no redirection and no interaction with a user so if I can grab it, I've got an endless all access pass to your users' data until they deny your app access to their data. I may be a little misinformed when I talk about the implicit flow with respect to a native client. I was mainly talking about its usage with respect to browser-based client. I wasn't aware about the auth code flows without secrets until the recent suggested flows for native clients included the auth code flow with out a secret. There seem to be many recent changes that muddied the original security considerations behind parameter and credentials requirements for the auth and implicit flows. Now there is auth code flow server (client secret required)/auth code flow for native apps (client secret optional) and implicit flow for browser clients (no refresh token)/implicit flow for native apps (optional refresh token?). It feels like there should be a well-defined or at least more narrowly-scoped flow for each intended usage instead of saying various clients can use the same flow but in various different ways. This makes it easy for developers to pick an choose which parameters they want to supply but difficult for server providers to validate requests. All that said, I do agree there is a user experience issue with the implicit flow. From a user's perspective if feels annoying to be asked the same question multiple times when the answer is always the same. I think I heard mention of facebook using tokens that don't expire. From their documentation, it sounds like they did the right thing. They don't do this by default but provide it as an option that the user has to authorize. "If your app needs an access token with an infinite expiry time (perhaps to take actions on the user's behalf after they are not using your app), you can request the *offline_access *permission." If I read that right, that says the user has to opt into the access_token not expiring. I believe this may be the smarted solution for now because it uses the scope parameter to gain this additional access which is using the actual protocol parameters as intended instead of hacking around them.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
