Authentication for REST web services
I'm starting to design a REST web service, and am unclear on the best approach to authentication. The service will allow individual users to access/manage their own data, so some type of user authentication is required. I've been looking at these options:
- OAuth
OAuth seems to be more about authorisation instead of authentication. I plan to handle authorisation natively within the services, so am not looking for a solution to this. But, is OAuth also appropriate for authentication?
- OpenID
OpenID certainly provides a solution for authentication, but this is geared more to allowing users to use their 3rd party credentials (Google, Yahoo, etc.) Though I would like to support this, this is not a primary concern for me, and I will definitely allow users to sign up with native credentials (email/password).
- HTTP Basic authentication
This is simple to implement, but it's my understanding that this may not be a very secure method. Also, it would seem to require the exchange of credentials for each access, but I'd prefer that the user authenticate once and then continue access via a session token.
- Custom authentication
Basically, roll my own login/token generation service, and require a valid token for access to all other resources (obviously, everything would be over SSL).
As well as creating the web services, I'll also be building a client (web) application which uses these services on behalf of a user, but I don't want the application to have to store user information/credentials/etc. So, something like this:
User (authenticates with email/password or 3rd party credentials) --> Web application (authenticates with application ID) --> Web services
And again, I want to allow others to build clients as well, so the middle tier can be any 3rd party application:
User (authenticates with email/password or 3rd party credentials) --> 3rd party application (authenticates with application ID) --> Web services
My very top-level requirements are:
- Secure (obviously)
- Native credentials
- Support for 3rd party credentials (Google, Yahoo, LinkedIn, etc.)
- Support multiple clients (web app, mobile app, 3rd party apps, etc.)
- Client credentials (just an app ID?)
- Login sessions that expire
- Authorisation is NOT required
So, my question is, based on the above (please let me know if this is too vague), is there a "best" approach? Are OAuth or OpenID appropriate, or am I making this too complicated, and instead should just roll my own authentication?
EDIT:
I think I will need to implement the following:
1) Native credentials/tokens (HTTP basic auth over SSL?)
2) An OpenID "Relying Party" to allow my api to use OpenIDs hosted elsewhere (i.e., "support for 3rd party credentials")
3) An OAuth "Consumer" to allow my api to access 3rd party services (like accessing a user's LinkedIn profile).
4) An OpenID "Provider" to allow people to use the api's native IDs elsewhere (optional)
5) An OAuth "Provider" to allow 3rd party apps to access my api on users' behalf (optional)
Does this seem right, or am I making this more complicated than it needs to be?
Answer
You could consider JWT (JSON Web Token) see JWT draft rfc. It would certainly meet your security and session expiration requirements. However being a draft standard it's unlikely to be widely used right now, this could change soon since JWT are part of OAuth 2.0. JWT are easy to implement in most languages and there are plenty of libraries already. As a simple explanation, a JWT token consist of 3 parts , the header , body and signature. The header and body are json objects being basee64url encoded (alphabets differ from base64 by the 2 last characters) and then signed with HMAC256 (or another algorithm specified in the header) the RFC explain how to exactly generate this signature. You might want to check this online token generator.
JWT are http headers and query parameters friendly.