8

For a REST API against which clients would be writing non-browser based, non-interactive applications, if OAuth2 is the authentication mechanism to be followed, then we would use the client credentials grant type for the authentication. Would that be the correct choice, and if so, how is it better than some other authentication mechanisms like Http basic/digest, or certification based mutual authentication?

10

OAuth is an authorization protocol, not an authentication protocol. Its role is not to tell you who is at the other end of the wire, but what that person can do. It so happens that OAuth can be abused into an authentication system: this is called OpenID Connect. The idea is that in order to give you authorization information (is the client allowed to do this or that ?), the OAuth server must first make sure of the identity of the client (who are we talking about ?); OpenID Connect is about reusing that inner authentication protocol ("if the OAuth server granted access, then, in particular, the OAuth server authenticated the client, and we have faith in the protocol used by the OAuth server, whatever it is").

If you do not have faith in what the OAuth server does to authenticate clients, then you can use other authentication methods such as passwords or client certificates. In that case, your server does the authentication, and then talks to the OAuth server: "I have Bob online, what is he allowed to do ?".

The question then boils down to: is the authentication layer in the OAuth server appropriate for your situation, or not ? This is up to you to decide. IF you decide to do the authentication yourself, then there are several methods with various characteristics. Which one is the best depends on the context; only a few remarks can be made in a generic way:

  • Whatever you do, use SSL. This is necessary to ensure that the authentication and authorisation you perform really applies, in a not-alterable way, to whatever requests the client subsequently sends to you.
  • Since you use SSL, don't do HTTP digest; use HTTP basic instead. SSL offers a much better protection than what HTTP digest offers (when compared to HTTP basic); and HTTP digest is not compatible with proper password server-side storage mechanisms (bcrypt...).
  • Client certificates are more complex for users, and make sense mostly when the authentication and the identity management are done by separate entities. If you just want to authenticate your users for your server, then certificates are overkill and probably not a good idea.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.