CODEWITHSUNDEEP
restauthenticationoauth
tntwyckoff
tntwyckoff

Reputation: 539

REST API security review

I'm working with some people who have had a product in development for a while, with apps on various platforms calling a web service which they're using as an API to store data.

The security model they have developed is not completely unlike others i've worked with, but it's very non-standard in a lot of ways. First, they require an API key for each client, which makes sense. Then there are some methods you can hit without authentication, great. when you need to do authenticated updates, however, this is how they do it:

First you call an endpoint with a username/password to get a "session" going on the server side. this session id is returned to the client after a successful login. Everything else you do that requires authentication takes a session id parameter which is required and the idea is that if you don't supply a valid session id then reject your requests.

I spent some time a while back doing authentication using OAuth and requiring tokens for authenticated requests on another project, so this feels weak to me. One obvious issue is the potential for someone to hijack someone's session by means of a brute-force attack, but I expect they'll dismiss that as just plain unlikely. Their session Id's are GUID's, which I suppose are huge and difficult to hack on some scale, plus you have to hit a valid session that's already established.

Am I missing something obvious, or is this perhaps good enough? I don't want to raise a stink about it and propose a platform-wide migration to OAuth if I can't make the case that it's really necessary.

Thanks for any help.

Upvotes: 0

Views: 104

Answers (2)

MvdD
MvdD

Reputation: 23436

First of all, requiring an API key is a form of authentication. It authenticates the client instead of the user.

Requiring an API key on all clients increases the risk of losing the key (especially when stored on untrusted clients like mobile devices).

Using session identifiers is not insecure, but it does require talking to the issuer (and likely doing a database lookup) for every call.

Security tokens can carry semantic information (claims) and can be validated on the called server (verifying signature), which improves scalability.

Upvotes: 0

orange77
orange77

Reputation: 1103

This sounds acceptable, just make sure that GUIDs are indeed generated with a strong random engine that can't be brute-forced, and that they expire after a while of no activity.

Upvotes: 1

Related Questions