[Prev] Thread [Next] |
[Prev] Date [Next]
[oauth] Re: Accessing protected resources with pre-signed header
Thu Jun 18 03:00:37 2009
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
On Jun 17, 10:57 pm, Mike Malone <[EMAIL PROTECTED]> 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.
> On Wed, Jun 17, 2009 at 5:15 AM, Eran Hammer-Lahav <[EMAIL PROTECTED]>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" <[EMAIL PROTECTED]> 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
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