内部Rest API中的oAuth用户身份验证

Question

I am building a REST API service that will not be public and only used by the client to access the resources on the server. There is no authorization of different consumers as the only consumer is the server.

I understand that 3 legged oAuth is the standard used by public API's like facebooks and I think I'm correct in assuming I am after 2 legged authentication but I cannot find a useful website describing it.

I need to use oAuth to access resources and/or change them. Obviously this should be protected. But I am unsure as to how about doing this within PHP. So if a user requests something like https://example.com/me/follow/123 by a post request the user 123 would only be followed if the user is logged.

I would also like public resources to only be accessed by a recognized client only. So if you access https://example.com/user/123 a 401 is given but if you access https://example.com/user/123?client_id=890 a result is given. This will not stop users who are not logged in getting public resources but will stop users who are not using a recognised client. More than a anythinging this is a way for me to track what clients are using the API in the future.

1) How do you go about logins and give the users a token that is sent with every API request?

2) How do I protect the API from being used by unrecognized clients?

I am sorry if any of my terminology or ideas are incorrect. My understanding of REST and oAuth is still very much developing.

Answer 1

您必须使用grant types=client credentials在OAuth标准点4.4中进行检查http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-4.4

Answer 2

I agree that cleint_credentials grand is the most secure and standard way of app level authentication -- your client sends a request for an access token to a specific resource and includes their client_id and client_secret in the Basic Auth header like this:

Authorization: Basic {base64 encode client_id:client_secret}

Then all subsequent requests use the access token as a Bearer token like this

Authorization: Bearer {access_token}

However... if this is a purely internal API and you don't need super security, it is also acceptable to simply validate the client_id (or apikey) on every single call. It means your API will need to look up (or cache) the validity of the apikey.

I suggest you send the apikey as a header for security so it isn't exposed on the query params, but it is also acceptable to send the apikey as a queryparam like

/myresource?apikey={client_id}

Not recommended from a security standpoint, but accepted practice in the API world.