Jorgito wrote: > > Hi! I'm new to this group. I am very grateful for the possibility it > brings me to ask questions, so thanks in advance ;) > > Reading the spec of OAuth there's something whose motivation I can't > understand. Why distinguishing between a Request Token first, and an > Access Token next? I agree that from a theoretical, software > engineering point of view the process of obtaining a ticket to access > the protected resource is different from the process of getting the > resource itself. However, in practice this approach leads to > additional delays during which the Service Provider is in a temporal > state. > At Netflix, we use all three in a significant manner.
The Consumer Key and Secret are used for access to our "low protection" movie catalog. In effect, they're our API Key and we only require two legged Auth to access. The Request Token is used not only to acquire the User Access Token, but also as part of the User Access Grant process (since we've got three parties in this, we require an extra step where the user grants permission for us to provide the access token, and we use the Request Token as the common element). It's a somewhat controversial and occasionally confusing step, but once folks understand the process, they actually agree that it's fairly simple. Finally, we use the User Access Token to grant the App permission to User protected resources such as their movie queue. > On the one hand, temporal states should be avoided as far as > possible in Web design. On the other hand, the User will notice that > the Consumer takes a significant time to retrieve the protected > resource (ok, this time will not be significant when accessing ONE > resource, but what if they are one thousand resources from the same > Service Provider? The additional time consequence from the distinction > between Request Token and Access token is increased 3 orders of > magnitude). > Honestly, it's not that much time, and frankly even with hundreds of thousands of keys, it can be handled by a single key in-memory cache. There are various optimizations one can do with the data. We process a fairly large number of two and three legged auth and barely see the CPU tick past 1%. > Don't get me wrong. I think that OAuth is a very interesting > technology and I can't wait to put my hands on it and develop my own > Web applications. I'm not criticizing OAuth. I'm asking these > questions sincerely because I really want to know why these decisions > have been taken. > Damn straight. It's called "Critical Thought" and it's sadly missing from a great many folks.What's nice is that there's also the concept of "Shared Knowledge" and thus why groups and forums like this are really, really handy. > Thank you for your patience. Greetings, > > > Jorgito > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
