1

I am currently working on web application which has front-end, and back-end. Back-end has RESTful architecture, or something that looks like RESTful to me (this is my first attempt to make something RESTful).

Few weeks ago I started to implement security for RESTful services.

I found out that there are few ways to that:

  1. basic http authentication

  2. Oauth 1.0

  3. Oauth 2.0

After some reading and watching videos on the subject this is what bugs me: With basic http authentication, front-end application sends username and password with every request.

Should those be the same end user credentials different for every user or should they be sort of "app credentials" for accessing services?

  • Who cares where it is stored? Storing it in a DB looks just fine to me. – dagnelies Feb 19 '15 at 10:55
  • Well I do because I don't fully understend the concept yet, that's why I'm asking. I don't understend, why the downvote? – Miljac Feb 19 '15 at 10:58
  • I agree, nothing wrong with storing it in a database. Keep it simple. – Brandon Feb 19 '15 at 10:58
  • @Miljac: hi, it's nothing against you. It's just that the question is very vague. That there are plently of tutorials about that stuff. That you could just google it. That it's just a matter of taste... – dagnelies Feb 19 '15 at 11:03
  • Well, I did google, but I felt a bit lost with too many information. I thought I understood, until I got to authentication. Where with basic http authentication you send username and password, long story short, I asked myself this question... But if it's vague, I'm really sorry for that, I will try to improve it – Miljac Feb 19 '15 at 11:12
3

When it comes to API authentication, those are the three most used models (in random order):

  1. Credentials are sent with every response.

  2. Credentials are sent once to generate an access key. The access key is then sent with every request.

  3. Credentials are sent once, and then a session (relying on cookies) is used to avoid repetitive authentication. Since one of the properties of REST is that it is stateless, this shouldn't be considered as REST and won't be discussed in this answer.

The first one has a benefit of simplicity: you don't have to deal with the additional access key, its generation (it should use cryptographically secure pseudo-random number generator), its validation and its invalidation (how long should the client stay inactive for the key to become obsolete?).

The drawback, on the other hand, is the impact in terms of performance. Instead of verifying credentials once, you should verify them at every request, which also means that you probably cannot use PBKDF2 with a high number of rounds, since it will take too much CPU power and slow down the API tremendously).

Note that in the first case, you will be sending credentials through HTTP's Authorization header. In the second case, Authorization header should not be used to send the access key, since it's not its purpose. Including the access key in the URI seems to be a common practice, although it results in long, cryptic URIs and pollutes HTTP logs.

Should those be the same end user credentials different for every user or should they be sort of "app credentials" for accessing services?

You shouldn't use user password. If you do it, this means that you stored it, somehow, somewhere, in plain text, and that's a very, very bad practice.

There are two ways to use an API:

  • Per-user usage. This is often the case where the third-party API is accessed through JavaScript on client side. For instance, if your website allows a user to view the list of his friends from another website, the list being loaded through JavaScript by calling this other website API, you'll usually have a per-user usage.

    In this case, there will be an association between the API account and the user account, so each user can access the API using a specific (randomly generated) client ID and the corresponding (cryptographically secure randomly generated) access key. The API should rely on the access key as its authentication means, but in any case should it receive or request the original user's password.

  • Per-application usage. This is often the case where you, and not your users, are using the third-party API. For instance, if you need to access some financial data, generate the reports and then sell those reports to the users (given that every paying user will have the same report), you're in this case.

    Here, you'll have a single client ID and the corresponding access key. You'll need to store them securely on your server and under no circumstance share it with your clients.

  • Can you recomend some literature or tutorial where I can read more about per-user association between API and user account? That was my original question about, unfortunately, poorly worded. – Miljac Feb 19 '15 at 13:36
  • @Miljac: I don't have any particular article to recommend. What I advise you, on the other hand, is to look as practical examples such as the APIs of Twilio, Amazon or Google. Note that off-site recommendations are off-topic on Stack Exchange, so if you've originally asked for off-site recommendations, I'm not surprised your question was downvoted. – Arseni Mourzenko Feb 19 '15 at 13:41
  • I did not ask for off-site recomendation, but I didn't know exact terminology to use, so it was kind of, as I said poorly worded. This Per-user usage section is exactly what I wanted to know, thank you for that. – Miljac Feb 19 '15 at 13:47

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.