search

phurni / authlogic_api

Authlogic plugin to allow API requests to be authenticated automatically by using an api_key/signature mechanism
MIT License
53 stars 7 forks source link

Question about background on this approach... #1

Closed barmstrong closed 14 years ago

barmstrong commented 14 years ago

Thanks for making/posting this!

Is there somewhere I can read up on this approach to authenticating API's? I saw Facebook uses something similar with their apps) but I don't feel like I quite understand it yet. Specifically...

If I understand the server side right...

The app_key never goes across the wire, so when it gets to the server, the server recomputes the signature using it's own app_key and makes sure it matches.

Ok I get this....but

  1. Why is the app_key used only in the GET and not in the POST then?
  2. Can't someone who intercepts your GET send the exact same message again, impersonating you? Granted this isn't quite as bad - they can only do over again a post you already made (replay attack). But still, could be used to write a bunch of stuff to someones account.

Regarding #2, I'm assuming this is why Facebook passes the microtime (num milliseconds) as an additional param? So maybe that is an additional precaution not used here.

Finally...is this a good way to authenticate BOTH a user and an app? I guess this is what I'm really trying to do. Haven't quite wrapped my head around it though.

Thanks again! Brian

test-org-rename commented 14 years ago

Hi,

Thanx for your post. Yes, facebook was the inspiration. Don't know if there is litterature about this mechanism, but I'll try to show you how it works.

The app_key is to identify who (an application) sent the request, so yes it goes through the wire. What never goes through the wire is the app_secret. This shared secret from the server and the client is used to hash the request. In this manner it is not possible for an attacker to compute a different request.

The client (application) sums the request params then add the secret and hashes it. The request is then sent to the server. The server does exactly the same computation, sum the request params (excluding the signature) then add the secret and hashes it and finally compare this to the passed signature. If they match, the request is considered authentic.

Yes, currently an attacker could re-issue the same request, the server will not notice the request comes from an attacker. As you said, it is the reason facebook adds the 'call_id' parameter. I'll make a revision to authlogic_api to take into account the same feature.

Finally, authlogic_api is a good way to authenticate an application. Not a user behind that application. I did this because I needed it in an intranet infrastructure. If you want to authenticate users and application you should have a look to OAuth.

Best Regards,

Pascal.

barmstrong commented 14 years ago

Thanks for your help! Makes more sense now. I think you're right OAuth is what I need to be looking into. Thanks!

mpestritto commented 12 years ago

Hi.

Good description on how your app works on server side. Thats what I understood from reading the documentation for the GET method. But I did not see the secret passed in POST requests. How does this library verify authenticity of a POST request? Just calc MD5 sum is not enough, anyone with appid can calc MD5 sum of post data and create a signature.
Please advise. Thanks Matt

phurni commented 12 years ago

Hi @mpestritto,

The secret never goes on the wire, it is used as a salt before hashed. For POST and PUT methods, the secret is added at the end of the body and this whole payload is hashed which becomes the signature. (as seen in the build_api_payload method)

But you are right, the docs doesn't mention where the secret is used for POST, I'll update that.

Best Regards