2

I'm currently in the process of writing an API that will interact with a web application, iPhone app, and Android app for my work. The API is pretty simple and deals with pilots and their availability.

Since I am creating the API and the client-side applications it seems to me that OAuth2 is overkill for this since I don't really care if username/password passes through the client applications.

I do need to have different user_roles such as 'Admin', 'Supervisor', and 'User' and then restrict access to API calls based on this.

Is there a simple way to go about this? Basic authentication over SSL?

  • 1
    You can implement tokens without implementing OAuth2. Look into access and refresh tokens with JWT – Jacob Hull Jul 15 '17 at 10:20
6

The problem with basic authentication over SSL is it depends on passing reversably-encoded user credentials with every API request. This is a security issue because unless you intend to make the user submit their credentials with every request, you'll have to store the user credentials some way on the client device or in the browser (browsers usually cache basic auth credentials and store them in a way that is difficult to clear). Any time user credentials are stored, it leaves room for somebody else to gain access to them.

It's much better to use some kind of token that is granted at login, has an expiration date, and can be revoked at any time. Tokens are safer to use because even if somebody gets access to the token, they only have access to your system not every system your user uses the same password with.

OAuth2 may be overkill for your apps, but it may be a good choice because it forces you into using some good security practices, and many people have been using it for a while, so it's rather mature as a security protocol. Any protocol that you come up with will likely contain security holes that you just haven't thought about. It's better to be safe than sorry.

5

You are right, OAuth2 is overkill in this specific case and despite the comments, it will add unnecessary complexity to the whole project. That being said, remember that OAuth2 is not an authentication protocol, so one more reason to leave it aside for now. Anyways, take a look to this article and get your own conclusions and decide if it's suitable for you.

The OAuth2 main goal is authorising different application providers to share data without the need to share the credentials too. I assume that it's not your case (yet).

For example:

I authorise Instagram to publish my photos on my Facebook's wall. And I authorise Facebook to share my data and my contacts with Instagram.

That's it. However, many developments out there implement OAuth2 as dedicated security servers (authorization and authentication). That's neither right nor wrong. It's just the solution that best serves their needs.

You never should implement something just because everyone else does it1. If you do, it's likely you will end up with an unsuitable solution. In security one of the most important concerns is suitability. Unsuitable security precautions may result in unexpected security holes.

The problems with basic authentications (among others) are two:

  • Weak encoding (base 64) and foreseeable format of the encrypted credentials.

  • Persistence in the client side.

Browsers store basic authentication headers in order to don't ask you the credentials over and over. That doesn't happen with asynchronous calls (Ajax), in consequence, we have to store the credentials somewhere on the client-side. That leads us to the LocalStorage and cookies, both sensible to XSS attacks.

This vulnerability is going to be present no matter what we store, however, If we had to choose, we should choose to expose a well-encrypted token, and this's not the case of the basic authentication.

While the first (encrypted tokens) may or may not make my account vulnerable, the second (base 64 encoded credentials) is totally giving away the keys of the home.

So what do? Due to you still have to implement a login process and you still need a solid token-based mechanism for authentication and authorization, JWT is probably your best choice.

It's simple, it's well documented and it's broadly supported by the community. And overall, it's suitable.

At this point, you might be interested in OWASP REST Security Cheat Sheet. Security is all about awareness and suitable precautions.2

Note: OAuth2 and JWT are not mutually exclusive. We can combine both. Finally, the security threats are different for web applications and for mobile applications and therefore the respective security measures. That's why suitability is important.


1: This doesn't mean that you have to re-invent the wheel. Hell no! Use OAuth2 when you need OAuth2. That's it 2: Whether you implement OAuth2 or JWT, SSL is a must

0

I don't think it's overkill. There are tons and tons of libraries for both client and server. This is a standard protocol used by pretty much everything today. Ignoring this standard because you think it's overkill is silly. Instead you should spend some time understanding what it is and the breadth of the standard. I'm sure it will be able to meet your use case.

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.