API Security Question

[TechBoyJK]

As I open the site up for developers to write external apps for, I'm
thinking I want to log both the developer's api key, as well as make
them register each 'app' they create.

1. Developer creates traditional user account on website
2. Developer applies for API Key
3. Upon approval, we associate user account to API KEY
4. Developer registers his/her first app and gets an 'appID'.
Developer has both API Key and app ID.
5. When making requests via API, they need to include both API Key and appID.
6. AppID and API Key is basically userID and password for the
application to access our site.



This way, I could set permissions/security levels for the apps. For
instance, I could allow someone to develop an APP that's read only.
Their registered app would have an AppID, and we could programatically
limit them to functions that only get data, but they can't post
anything. Any functions that write data would have a simple security
check that queries the permissions of the app making the request.

Does this seem logical?

Example: Password Hint Request

http://company.com/config/cfc/users.cfc?method=getPassHint&email=jason@cnn.com

If you hit that in a browser, you can see it returns in JSON format.

What I'm wanting to do is make it so these requests won't work unless
it's an authorized request. So the URL should look like this

http://company.com/config/cfc/users...son@cnn.com&appID=456&apiKey=XDJKJ39IDL923408

*This will all go over https once I get around to it.

 

[Crusty]

If every single request the user makes must contain the API key AND AppID you might as well just not have an API Key at all. It's just constant data being sent for no reason when you could have just generated a unique(systemwide) AppID in the first place.

If there are API requests that only need the API Key then you're stuck splitting it up into two fields.

Since you mention using SSL, why aren't you just using Basic HTTP Authentication to pass your credentials? It's already implemented and works in all browsers. When it comes down to your security, you are much better off using trusted libraries and protocols than trying to re-invent the wheel.

 

[TechBoyJK]

If every single request the user makes must contain the API key AND AppID you might as well just not have an API Key at all. It's just constant data being sent for no reason when you could have just generated a unique(systemwide) AppID in the first place.

If there are API requests that only need the API Key then you're stuck splitting it up into two fields.

Since you mention using SSL, why aren't you just using Basic HTTP Authentication to pass your credentials? It's already implemented and works in all browsers. When it comes down to your security, you are much better off using trusted libraries and protocols than trying to re-invent the wheel.

I'm talking about external applications authenticating themselves, not users.

AppID would for the application, not the user.
AppKey would be a string that only the developer would know.

When their app tries to use our API, I need to authenticate the app. If a developer writes 3 apps, I want to be able to differentiate between the apps (for logging). Everytime the app makes a request, it needs to validate itself.

HTTP AUTH won't work here, as I'm not authenticating with the webserver. Credentials are being passed to the application server, which queries a database containing the user and a hash of the password.

 

[Crusty]

I'm talking about external applications authenticating themselves, not users.

AppID would for the application, not the user.
AppKey would be a string that only the developer would know.

When their app tries to use our API, I need to authenticate the app. If a developer writes 3 apps, I want to be able to differentiate between the apps (for logging). Everytime the app makes a request, it needs to validate itself.

HTTP AUTH won't work here, as I'm not authenticating with the webserver. Credentials are being passed to the application server, which queries a database containing the user and a hash of the password.

I'm referring to the USER of your API, which happens to be an 'app' as you have defined it. Regardless, that's just semantics. You're missing my point about the API Key though. If the 'app' is required to send both the API Key AND AppID with every single request then what do you need the API Key for? Just make the AppID globally unique and you know which application is making a request and therefore which developer made the request by association of AppID <-> Developer.

edit: Not sure why you think HTTP Auth won't work, there's no reason Apache or whatever your webserver is can't be configured to read it's credentials from your database. The earlier you reject a request because of invalid credentials the safer you are going to be.

 

[TechBoyJK]

I'm referring to the USER of your API, which happens to be an 'app' as you have defined it. Regardless, that's just semantics. You're missing my point about the API Key though. If the 'app' is required to send both the API Key AND AppID with every single request then what do you need the API Key for? Just make the AppID globally unique and you know which application is making a request and therefore which developer made the request by association of AppID <-> Developer.

edit: Not sure why you think HTTP Auth won't work, there's no reason Apache or whatever your webserver is can't be configured to read it's credentials from your database. The earlier you reject a request because of invalid credentials the safer you are going to be.

See I always thought httpAuth relied on the database of the OS hosting the webserver..

I don't want any annoying brower login window popups. Soooo 1990's.

Let's say I have a login form on the website. It's a simple form, with two form fields.

Email
Password

Right now, the user submits the form, and the page it posts to takes each form variable, and queries a database to see if it's a match. If it matches, a session is started, etc. etc. It's done via https so nothing is sent in clear text.

#I hash the passwords, so when I compare the submitted pass against the db, I just hash the submitted pass and compare the hash's.

How do I utilize httpauth in place of the form?

 

[Crusty]

See I always thought httpAuth relied on the database of the OS hosting the webserver..

I don't want any annoying brower login window popups. Soooo 1990's.

Let's say I have a login form on the website. It's a simple form, with two form fields.

Email
Password

Right now, the user submits the form, and the page it posts to takes each form variable, and queries a database to see if it's a match. If it matches, a session is started, etc. etc. It's done via https so nothing is sent in clear text.

#I hash the passwords, so when I compare the submitted pass against the db, I just hash the submitted pass and compare the hash's.

How do I utilize httpauth in place of the form?

I thought this was for an API? Why would there be a web browser involved? For human interaction, I agree, a traditional logon form is ideal....

 

[TechBoyJK]

I thought this was for an API? Why would there be a web browser involved? For human interaction, I agree, a traditional logon form is ideal....

There's 2 parts. Yes, in the OP I'm talking about remote access from outside apps talking to my application server, but there's ALSO a website. The website is where i use the form mentioned above.

For remote apps(android/iphone), I would assume they would use a form just the same, and when user submitted it, it would post the data to the API, and the API would return results based on the success/failure of the called procedure.

Let me ask you this, since it seems everything I pull up about HTTPAUTH was published in the 80's(joke) or it's all related to specific software.

If I want to use httpauth with a url, how would I pass a user/pass with it

http://company.com/mylogin.cfm&user=???&password=????

 

[Crusty]

There's 2 parts. Yes, in the OP I'm talking about remote access from outside apps talking to my application server, but there's ALSO a website. The website is where i use the form mentioned above.

For remote apps(android/iphone), I would assume they would use a form just the same, and when user submitted it, it would post the data to the API, and the API would return results based on the success/failure of the called procedure.

Let me ask you this, since it seems everything I pull up about HTTPAUTH was published in the 80's(joke) or it's all related to specific software.

If I want to use httpauth with a url, how would I pass a user/pass with it

http://company.com/mylogin.cfm&user=???&password=????

Well that's a lot different than you were explaining. If you're planning on going down that route then I would say you are stuck with the normal forms.

So are you expecting application developers to use your web front end as their API or is the only common point between the API and website the login form?

To answer your question on HTTP Auth, it looks like this. https://username:password@www.mysite.com

 

[sourceninja]

This is what oauth was made for...

 

[beginner99]

I don't want any annoying brower login window popups. Soooo 1990's.

these pop-ups only appear if you do not send credentials but since this will be done programatically in the background it is a non-issue.

The alternative was mentioned multiple times in the other thread of you. simply use POST to submit the API Key and appID.

Or another alternative is to submit your keys in custom http headers:
http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions

The one problem I see (but I might be 100% wrong) is that in all these cases you need to store the API Key and appID on the client (eg. mobile Phone). if you put the key in your code and the language is Java (eg on Andorid), it is simple to just "decompile" java and voila you see the key.