Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app
User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A & B. Client ID is the same across the two devices. - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on device B is 1275375611. The provider, mega_app, does not issue multiple tokens for the same grant request (scope, client_id). This simplifies provider implementation but also helps enforce the correct user UI with respect to credential control at http://megaworld.com/my/apps - that is, the provider can't accurately know if frankie_uk has authorized one software instance twice on the same device, or multiple software instances once each (across multiple devices). Thus, the my/apps UI shows one authorization for "Megaworld for iOS" and thus one option to de-authorize this client_id (and thus all installed instances of the single software program with ID mega_app). Regardless if age or timestamp is used, if the implementation for validating the time value is sequential (perhaps with some window of error) then one device will have all its OAuth requests rejected as soon as the other presents a request. If timestamps are used the one with the older clock (device B) is rejected. If age is used, the one with the highest value of time (in this case, the more correct client) will be rejected as age will be calculated to be smaller than device B with an incorrect clock. If you also consider the case where device A and B have the same value for current time (UTC time, let's say) then age fails for device B after device A submits a request since device B thinks the credential is younger than device A. Timestamp does not fail in this case (because clocks are already sync'd). Only when the timestamp is a unified standard like UTC can both device A and B both use token 89ARC. If client B has it's request rejected it can quickly check UTC from any reasonable source (including api.megaworld.com) to correct its clock. Even better, it can politely check the correct system time on a regular basis and cache the offset between UTC and device time. Though experience may show that many software developers don't currently do this clock correction, it is trivial to adopt as a best practice. (Many software developer also don't routinely review their software for security or stability vulnerabilities of any sort.) Certainly is nothing for the small percentage of well-written high-value clients such as Firefox, TweetDeck or any serious effort with even moderate distribution or engineering resources. skylar On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > This is not true. > > The age value has to be monotonically increasing, but not necessarily unique. > Really, any counter will do. The reason why timestamp isn't any better than > age or sequence is because ultimately, it is the server's memory restriction > which determines the nonces storage size, not anything else (like a time > limit). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
