API Security/Authorization

Question

I am in need of advice on how best to tackle the following scenario and best practices to implement it.

Our company wants to overhaul its old IT systems and create new website app(s) and possibly mobile apps down the line for its employees and contractors to interact with.

So i was thinking about creating an api that both the website apps and mobile apps could be created from...

https://api.company.com/v1

The advice i need is in relation to security/authorization of the api. My thoughts at present in how to implement this would be that the employees/contractors would interact with the api through the companys website app(s)/mobile apps which would then communicate with the api and set the appropriate access permissions

WebsiteApp.company.com ->>> api.company.com/v1
mobileapp ->>> api.company.com/v1

First thoughts is just setting up a username and password for each user on the api side and let both the websiteapps and mobile apps use this. The problem however is that the contractors and possible some employees cannot be fully trusted and could pass on username and passwords to third parties without the company's permission. So my question is really what other security/authorization/authentication strategies should i be looking at to overcome this situation. In a perfect world each user would have to authorize each device/mobileapp/websiteapp he/she wants to access the api from...

Is OAuth 2.0 capable of this?, not sure if its capable of specific user/device/website scenario though ?

Technologies thinking of using are:-

API

Node.js with (Express js? or Restify?) , MongoDb

Consumer Apps

Website Apps (Angular Js, Backbone etc..)
Mobile Apps (PhoneGap, Jquery Mobile etc..)

Many Thanks

Jonathan

score 1 · Accepted Answer · answered Feb 07 '13 at 18:01

It seems that your main concern is that you can't trust the people you are giving access to, and if this is the case, you probably shouldn't be trying to give them access in the first place. If these apps are to be used for any confidential information or intellectual property that you are worried about someone else seeing if the contractor/employee gives away their password, then you have to consider the contractor/employee just taking the information and giving it away.

In this situation your username/password should suffice for authentication, however you should also consider very tight permissions on who can access what. If you are worried about information getting out, everything should be shown on a need-to-know basis. If a contractor doesn't need a specific piece of information, make sure it isn't provided to his account.

You could also consider tracking the locations (IPs) that an account is being accessed from. Perhaps when an account is accessed from a new location have the employee/contractor complete some task to validate the account; which could be anything from entering a validation code (similar to a two-factor authentication), to calling a help-line and having the location authorized.

Thanks Nick, good points made. IP addressees are tough to lock down, especially with mobile devices, spoofing, proxy servers etc.. Hmm MAC addresses are worth a thought? That really should be set at the firewall level ?. So i take it OAuth 2 is not really going to help in this situation?. — Jonathan Turkington, Feb 07 '13 at 23:28
I was speaking more for web UI's when talking about IPs. For mobile devices you could possibly look at UDID, however I havn't personally done this and my info may be out of date. Apple's developer docs may be a good place to get some information about this. — Nick Mitchinson, Feb 07 '13 at 23:42

score 0 · Answer 2 · edited Oct 07 '21 at 07:15

This might be a bit late, but as i am going through the same process (What is the correct flow when using oAuth with the Resource Owners Passwords Credentials Grant)

We have not figured out the core implementation what you want to do sounds similar to what we are trying to do for our service.

From my understanding it depends on the apps and if they are trusted or not and what you plan to do with your API moving forwards. If the apps are trusted you could potentially use HTTP-Basic over SSL which is a viable solution.

For us, we are going to create a suite of trusted official apps (Web, Mobile etc) via the API and then open it up, so we are deciding to go through the pain of oAuth2 where for our apps we will use the Resource Owners Passwords Credentials Grant type where you swap a users user name and password for a token which is what the client will use to interact with your API with the trust implicitly defined.

When we open up the API for 3rd party consumption this model wont work and we will go through the processes that all the major sites do and get explicit permission from the user on what the 3rd party apps can do with their data.

API Security/Authorization

2 Answers2