CODEWITHSUNDEEP
securityrestoauth
Alex B
Alex B

Reputation: 84802

What's the current state of wisdom for REST API security?

I'm receiving mixed signals on the web regarding preferred REST API authentication/authorization mechanisms, especially for mobile applications.

  1. There is OAuth 1.0, but it's claimed to be more complicated than it needs to be and doesn't support native clients too well (callback URLs are very browser-centric). On the other hand, there is one major provider that supports it (Twitter).
  2. Then there is OAuth 2.0, which is supposed to be an improvement over 1.0, and it gets rid of client-side crypto in it default incantation (replaced with bearer tokens), but some people are of the opinion that it's broken by design, and bearer tokens are no better than cookies. An SSL certificate from a sketchy provider can trick a mobile client more easily into believing that the endpoint is a trusted authority. However two major providers (Google and Facebook) support it.
  3. And then there are people, who advocate sidestepping the whole mess and rolling your own.

So which is it?

Upvotes: 4

Views: 255

Answers (2)

Tom van der Woerdt
Tom van der Woerdt

Reputation: 29975

I'd recommend OAuth 2, but with additional certificate checks in the clients. If your certificate comes from Verisign, then invalidate all certificates from other CAs. Make sure to always get your certificates at the same CA though, unless you like distributing updates.

In the end, however, only a client can verify that the connection to the server is completely safe. Never forget that.

Upvotes: 1

Brian Kelly
Brian Kelly

Reputation: 19295

This is going to sound like a hedge, but the answer is "whatever is appropriate for your application".

3rd-party authentication systems like OAuth and OpenID have their place, and they are perfect for some applications, especially for the kinds of systems that would allow clients to become API users without having to fork over their personal credentials to yet another server system.

However, you might be building a system that doesn't have that constraint or requirement, and it may be reasonable to ask your clients to simply create an account on your server. In that case, you can probably simplify things dramatically by using HTTPS and Basic Auth. Have the client pass their username/password in the appropriate header and ensure that your connection is SSL-protected. Or, have the client use a certificate for their credentials.

I would suggest you start by enumerating what "security" means to you, and work from the ground up. Consider every related facet like integrity guarantees, non-repudiation, replay protection, client impact, performance and API usability. From there, figure out if all you need is HTTPS/basic auth, or if you also need to add API keys, OAuth, OpenID, checksums, etc.

Upvotes: 3

Related Questions