I would suspect that many users are overwhelmed when authorizing many fine grained scopes and don't fully understand the risks. Many popular sites ask for offline access straight away upon connecting to Facebook (Foursquare, Quora, Instagram, etc). This offline access token, has a higher chance of being exposed, like if you use the cookie: true option in the Facebook JS SDK (which Foursquare does), which sets a Javascript accessible non secure cookie on your domain which now means that if Foursquare makes a non secure http request to foursquare.com a non expiring bearer token will go out in plaintext. Foursquare is https only but many sites that use the JS SDK aren't.
The biggest difference between a refresh token and a non-expiring access token is that the refresh token needs to be verified by the authorization server only whereas the access token needs to be verified by the resource servers. ------- Here is the rationale in Scalable OAuth Extension (http://wiki.oauth.net/w/page/12238549/ScalableOAuth#RationaleforRenewableAccessTokensSessions) which was a predecessor to OAuth WRAP and OAuth 2: Rationale for Renewable Access Tokens (Sessions) Many Service Providers have the concept of a Session credential with a finite lifetime. Consumers authenticate with the Service Provider's Authentication Service to obtain a Session credential to access the Service Provider's protected resources. When the Session credential expires, the consumer is able to obtain a new Session credential by re-authenticating with the Authentication service. The primary benefit to this architecture is that Session credentials do not need to be revocable if they expire quickly, and that protected resources can be returned without a database lookup to verify that the consumer is still authorized. Rationale for Auth Session (aka Refresh Secret) Service Providers often run their Authentication Service separately from other protected resources. The Authentication Service is usually strictly monitored and controlled, while other Protected Resources may be running relatively new and unproven code. In the event that a Protected Resource is compromised (the SP gets hacked), it is desirable to prevent the intruder from being able to continue to compromise the system after the vulnerability has been fixed. Issuing credentials with a finite lifetime limits the duration that the intruder can continue to use compromised credentials. Issuing a credential to a Consumer that is not known by the Protected Resource but is known by the Authentication Service can enable an Service Provider to revoke access to an intruder without requiring consumers to be reauthorized. ------ Another related issue with Native Apps like iPhone Apps that can't be shipped with a client secret is the end user's expectation to stay "logged in." On May 31, 2011, at 7:12 PM, Doug Tangren wrote: > > "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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
