CODEWITHSUNDEEP
restrestful-authenticationrestful-architecture
David Kerr
David Kerr

Reputation: 1476

Is solely using HTTPS adequate for securing API RESTful web-application?

I'm researching a new web-application that I want to develop using HATEOAS, RESTful principles. I'm looking into authentication schemes and the information for authentication of web-apps (via browsers, not machine-to-machine), seems a bit lacking.

After establishing an HTTPS session and initial log-on there doesn't seem to be any need for tokens, cookies, HMAC's, nonces, etc. to be passed. Nor does the Basic-Authentication or HMAC, OAuth, etc seem to matter: the HTTPS session is secure.

I'm probably missing something. Here's how I imagine my solution working: -

  1. User navigates to the login page of the web-application (HTTPS://acme.com/login)
  2. User specifies username and password
  3. Web-service validates the username and password: allows access to authorized resources

For the server to identify the authenticated user on subsequent requests, it could either: -

  1. pass the clear-text user name as a header or cookie - this is RESTful, IMO
  2. use the SSL session ID (if available to framework), looking up the user. This is not quite so RESTful as the session ID needs storing

I see no reason to use anything else than HTTPS. What am I missing, what vulnerabilities or missing functionality?

Thanks!

Upvotes: 0

Views: 158

Answers (2)

Adrian Edwards
Adrian Edwards

Reputation: 579

HTTP Basic Authentication (i.e., username and password) + HTTPS is generally considered to be secure enough for most REST APIs, especially for internal use. However without a unique nonce (or transaction ID), you are vulnerable to replay attacks.

For example, imagine an attacker was able to record a genuine PUT request to create some new record in your database. They could then replay that message in a loop to launch a DoS attack on your API by filling up your database tables. Although the message was encrypted via SSL, it still contains valid credentials, so each replayed request from the attacker would be dutifully decrypted and successfully authenticated by your API.

HTTP Digest Authentication includes a nonce that changes for each request and is therefore considered a more secure option.

Upvotes: 3

Zerkz
Zerkz

Reputation: 721

You have to define security here. SSL is fairly secure (despite there being issues recently with OpenSSL/Heartbleed).

However, as I see you are using a username and password/login, why not combine HTTP Basic and HTTPS? Most frameworks support basic auth, so. Simply authenticate the user every time you make a call. This is the only way to be RESTFul with Authentication, as you want to be stateless.

Upvotes: 1

Related Questions