Thanks for the reply, Mike and Eran. I will go on with pure OAuth implementation for now and if anything shows up will let you guys know.
Thanks, Monis Iqbal On Jun 17, 10:57 pm, Mike Malone <mjmal...@gmail.com> wrote: > Eran's right, there are ways around this, but I'm wondering what sort of > mobile device you're working with that doesn't have the capacity to sign > each request. It's really not that much overhead unless you're making > hundreds or thousands of requests per second (which is unlikely on a mobile > device). You may be overestimating the expense of generating a signature. > I'd suggest giving signing a try before spending time coming up with a more > "clever" solution ;). I'd definitely be interested in more details if you're > really unable to sign requests due to resource constraints. > > Mike > > On Wed, Jun 17, 2009 at 5:15 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > > > > > One way is for the device to use a signing proxy on a server. Another is > > for > > you to use very short lived credentials and not require signatures - there > > will still be a replay attack possible but the window of the attack will be > > much smaller. Yahoo!'s BBAuth protocol works this way. But at this point > > this will no longer be OAuth but some other protocol. > > > EHL > > > On 6/17/09 3:50 AM, "Monis" <monisiq...@gmail.com> wrote: > > > > Section 7 of OAuth Core directs us to 'sign' the requests even after > > > we have received a granted access token. > > > This signing ensures security with each request made to the SP. > > > > We have a case for implementing OAuth Consumers on mobile devices and > > > the signing of each request to access protected resources could be > > > costly, considering the sparse resources on the device. > > > > Can there be a way around this to not sign request every time and once > > > we have an authorized access token, send it as is for future retrieval > > > of protected resources? > > > We understand that replay attacks are possible if we don't follow the > > > unique nonce and timestamp constraints (Section 8) but we don't want > > > the replay attacks either :) > > > > We also looked at OAuth Session extension, but again each request has > > > to be signed in order to fetch protected content. > > > > Thanks, > > > Monis Iqbal > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
