I get what you mean now but following issues will make this scheme very hard to implement,
1. Where does first nonce come from when consumer gets request token? All OAuth message needs to be signed with nonce. 2. How do you track next nonce when you have multiple sessions going on at the same time. Remember HTTP is stateless. You must use some other parameters to track the session. 3. How do you keep client/server in sync? For example, server forgets about next nonce when it restarts. Some sync process is needed to recover from this. 4. Consumer would be limited to serialize all its requests. Currently, a consumer can send multiple requests to get protected resources upon receiving access token. With this scheme, it's not possible anymore. You can get away with most of the issues by asking for a nonce every time but that adds a round-trip for each request. Zhihong On Mar 26, 11:44 am, joshthecoder <[email protected]> wrote: > I don't think an extra round trip would be needed to get the nonce > from the server. > > Get request token --> Service provider > Consumer <-- Request token along with next nonce in the header > Get access token --> Service provider > Consumer <-- Access token along with next nonce > > Get protected resource --> Service provider > Consumer <-- Protected resource with next nonce in header > > So each time we send a request to the service provider we get in > return the next nonce value in the response header. > There is no extra trips to the server since we just carry the next > nonce on the response packet. > > On Mar 26, 9:34 am, Zhihong <[email protected]> wrote: > > > Don't you need another trip to get the server generated nonce? So a > > round-trip is saved by using client generated nonce. > > > I just posted help in another thread > > >http://groups.google.com/group/oauth/browse_thread/thread/ff93d23e073... > > > Our problem would be solved if the nonce is generated by server but I > > don't think this justifies an extra round-trip. > > > Zhihong > > > On Mar 25, 5:23 pm, joshthecoder <[email protected]> wrote: > > > > I've been reading up on the oauth specs and when came to the section > > > about nonce and timestamps I wondered "why not have the server send > > > the nonce?". > > > > Benefits of this: > > > + Server only needs to track the last nonce it sent to validate the > > > next request > > > + Don't need to store every nonce ever used > > > > When the server responds back from the previous request it can include > > > the next nonce value in the header. > > > So when we construct our next signature we have our next nonce. > > > Attackers still can't construct a valid signature even if they see the > > > next nonce. > > > > So why have the client generate the nonce on the fly? I'm no security > > > professional, so I might be overlooking a flaw with the above method. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
