php REST API auth元数据的良好实践

Question

I'm building a REST api using PHP 5.4 and I'm putting in my own custom auth library. I'm closely following the format that 2-legged OAUTH uses. (ref: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/)

Following this spec I have several pieces of metadata that need to be sent with each request so that I can securely authenticate the user.

1. AppId -> This is to verify who is sending the request. Also to know which secret key to use to generate the HMAC checksum server side.
2. Timestamp -> This is to deal with replay attacks.
3. Checksum -> This is a HMAC hash to make sure the request wasn't tampered with.
4. AccessToken -> Would be used with every request after the initial authentication.

I was just wondering what would be the best practice for sending all this metadata?

I was thinking of creating custom headers and sending this stuff in there. This way I could separate this data from the actual parameters the function needs, but I'm not sure that's the best practice.

Ex: MY-API-APP-ID: 243242, MY-API-TIMESTAMP: 123123123 etc...

Or

Should all these things just be passed as parameters with every request?

What about GET methods, should they just be placed in the query string? (?timestamp=12312312&appId=123123...)

Thanks!

Answer 1

I actually did something exactly like this not too long ago. I wrote my own API authenticator as a Codeigniter library, and just autoloaded it so that it checked every page request coming through.

I decided to send everything in custom headers upon every request:

Auth-Token
Auth-Device
Auth-Timestamp
Auth-Hash

I don't recommend doing these in GET parameters simply because it makes it more cumbersome to work with the URL, and it kinda stops being RESTful at that point.

That said, I'm sure some people would point out that you shouldn't be creating custom request headers, and truthfully I'm sure there is a standard practice for how you ARE supposed to use headers in authentication solutions. But the application and API worked perfectly so I'm happy with my "eh, it works" solution.

But also note that we used SSL which encrypted the headers and prevented any sort of sniffing or man in the middle attack.