See below... Phil phil.h...@oracle.com
On 2011-04-04, at 10:47 AM, Kris Selden wrote: > A typical iPhone app cannot be shipped with a client secret and rightly or > wrongly users expect to only have to enter their credentials once. My understanding (and I'm not an iOS expert) is that each iOS application has a secure keystore where the client credential could be stored. I am told this is fairly straight forward. The client app would issue a call out to the external safari browser for the authorization with a redirect back to the app registered (local redirect) such as myapp://authorization_code Note that in security considerations it is recommended against having an app collect user credentials directly. It is always preferred to use the external browser. This is so that the user can see the UI as being legit and that appropriate security measures are in place. It also protects the client app from problems that might occur from screen scraping a service provider UI that is subject to change. > > What is the best profile to use for an app that can't have a client secret > and needs a refresh token or a long lived access token? You can use the typical client credential flow as per my comment above. If no client credential you are forced to use "Implicit" which I don't believe was intended for these types of apps. Note that Implicit also is restricted to uid/password type user credential. > > Why doesn't implicit_grant have a refresh_token? I would think a non-expiring > access_token like FB offline_access would be worse option since it is > transmitted to more end points. The issuing of a token in Implicit flow depends solely on the authentication of the end-user. Without client credentials you can't authenticate the client to refresh the token. Thus you must repeat the implicit flow every time. > > A lot of FB Connect sites request offline_access when you connect. Like > Foursquare, Quora, Gowalla for example. > > On Mar 31, 2011, at 6:00 PM, Marius Scurtescu wrote: > >> On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>> Done. >>> >>> It isn't quite what the flow shows in the earlier diagram. I was originally >>> avoiding client type and trying to focus on section 4 options. >>> >>> But this should be a better diagram. >>> >>> http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html >> >> A native app with no client secret is still advised to use the >> implicit grant, which is wrong IMO. >> >> The right question I think is "does the client need long term offline >> access"? >> >> JavaScript clients typically don't need offline access (only with the >> user at the browser). Some native apps and web apps could be OK with a >> short term offline access, one off import for example. >> >> Marius >> _______________________________________________ >> 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
