Universal way to authenticate clients and secure a RESTful api
I've been digging through stackoverflow / security.stackexchange threads and getting no definite answers on providing a universal way for clients to securely consume RESTful services I'm am building through asp.net's web api. In searching for this answer, I see "authorization" and "authentication" used interchangeably, so I want to point out that I am merely wanting to verify both a requests identity and legitimacy. So, at this point, I am not authenticating users.
Amazon's model seems to be the model referenced when "rolling your own," but, in this context, I do understand Amazon has supplied the "papers" per say, so not much reinvention going on here. This post, Designing a Secure REST (Web) API without OAuth, was super helpful.
What I gather is:
I have few problems with 2 that, perhaps, my mind can't wrap itself around. First, isn't an app secret supposed to be secret? So, if a javascript client makes a request doesn't this compromise the app key's secrecy? Why have an app secret then when I can verify the requests identity through a combination of verifying app key, nonce value, and server ip? I do understand that a server side language such as php, ruby, or c#.net wouldn't expose the secret, but I would like this to be universally secure for JS and compiled languages alike.
Finally, Facebook has a developer security checklist telling developers to "Never include your App Secret in client-side or decompilable code," which would suggest an encrypted web.config or the like to me. This solution wouldn't work for exposing the REST service to anyone consuming via javascript.
Other threads I've combed through:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
https://developers.facebook.com/docs/facebook-login/security/
Best Practices for securing a REST API / web service
Security of REST authentication schemes
HTTP Basic Authentication instead of TLS client certification
RESTful Authentication
The way I secure my app is with OpenID Connect. For your example, the client you are talking about in #2 would be the RP (resource provider) and an authentication system like Google would be your OP (OpenID provider)
An app key / secret must be supplied by the client to verify who they are.
would actually be your application and your client secret would not leave your server any more than your /etc/passwd file. This secret is what is used by the RP to talk to the OP to get the data.
The flow in a nutshell is
/restapi