I guess, in the ideal world, the app provider provide a group signature for the app and each client establishes individual keys with AS, but that is not the way current oauth is architected. Maybe the next step after the current set of the new work items are finished.
=nat via iPhone On 2012/06/08, at 23:51, John Bradley <[email protected]> wrote: > The implicit flow doesn't allow for refresh tokens. > > The refresh token mechanism allows for the AS to revoke access to the RS when > a relatively short lived access_token expires. > > Some people seem to prefer having the RS make a callback to the AS on each > access, and not use refresh tokens. > There tradeoffs each way. Issuing a non expiring access_token to the client > with no way to revoke it is quite likely a bad idea. > > I think you are correct that for a native client directly talking to the AS > the implicit flow is no more likely to have token exposed than code. > > The devil is in the details though, I am not recommending implicit over code, > the right one to use will depend on multiple factors. > > John B. > On 2012-06-08, at 9:28 AM, Lewis Adam-CAL022 wrote: > >> Hi all, >> >> I'm looking for a better understanding of why the code flow is recommended >> as the preferred OAuth flow, even when used for native (public) clients. >> >> I totally get why it is preferred for confidential clients, as explained in >> section 1.3.1. of the version 26 of the draft. The first reason is the >> ability of the token endpoint to authenticate the client - which doesn't >> really apply in the case of native (public) clients. The second reason >> cited is the ability to communicate the access token directly to the client, >> without exposing it to the UA and possibly leaking the access token. This >> is probably the one where I don't fully understand the security risk. >> >> In the code flow, the code obviously does flow through the UA, which could >> also be exposed to malicious clients executing on the device. And a >> malicious client that steals this code could exchange it for the access >> token. >> >> Now ... I assume the reason it is still recommended is that unlike an >> access-token, the code can only be used ONCE in exchange for a token, and if >> a rogue clients grabs it and then the legit clients grabs it and each >> present it to the token endpoint in attempt to get the token, the token >> endpoint can detect that it has been compromised (as it has been presented >> twice) and thus cut the attack short? Or is there more to it than that? >> >> I'm asking because the implicit flow avoids an additional roundtrip, and my >> clients will run over (at times) very anemic bandwidths. I want to fully >> understand the security implications vs. performance tradeoffs before making >> a decision. >> >> Tx! >> adam >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
