I’m currently working to specify my company’s new partner/public API, which will be a resource-oriented RESTful web service. The missing piece of the puzzle at the moment is authentication/authorization.
The requirements are:
- Initially it must work for a server-to-server environment, e.g. a server application must be able to identify itself so that we know who is calling the API.
- In future, we would like to allow it to impersonate user accounts, so as well as the server being identified it would have a token that represents a user account for a limited period of time.
OAuth seems to be ideal for (2) with the workflow of getting a token, redirecting to the website where the user enters their credentials to authorize it, and then using that token which identifies/authenticates both the application and the user.
However, from what I have read, I don’t know if it is suitable for (1) – i.e. is there any way that OAuth can be used just to identify the calling application without having a valid user-specific token and thus not needing to be redirected to a web page for them to enter their credentials?
Yes, the lifetime of the token can be set not to expire until you say so. So, you’d (manually) complete the authentication and authorisation, and save the authorized token for later use.
(You can use any test client to help you complete that manual part, or while you’re implementing the server yourself: use a so-called two-legged OAuth.)