Secure REST API without user authentification (no credentials)

Question

I've been struggling for 2 days now on how to secure a REST API without user authentification.

What does it mean ?

In my AngularJS application I identify an user by sending a GET request to an existing service (companydomain/userinfo) which I must use. I'm not sure how this work since I am not the author of this piece of code but the point is that I get the information about the user in the response as JSON (active directory name, phone in the company...).

This is all I have to identify an user.

What I did

Now, I found a lot of resources talking about OAuth, unique token, etc. but nothing seems to match with my issue. I implemented a token system but it's plain useless since I can't be sure of the authenticity of the requester.

1. User open the application. Application ask the service about the information related to the user. companydomain/userinfo
2. Application request a token to the server (nodejs & express), based on the information returned. /api/token/get/{user_info}
3. Server generates an unique token and store it in memory with expiration date and owner. The server also check in the table "authorized users" if the user exists (based on the active directory name), if not a new entry is added to it.
4. Application send the token along each request to the API. /api/entry/delete/{entry_id}

I think you see what is wrong here, an attacker could easily make a corrupted request to the API to get a legit token. So my question is :

How can I manage to secure my API since users don't use credentials to authentify ?

I hope my question is clear enough and at this point I am not even sure I can get around this issue without adding a credentials system.

Answer 1

You might want to look at Passport. It is a platform that allows you to easily add authentication to your application. There are many authentication strategies available. I am using Passport in a Node.js application implementing my own hmac strategy.

To authenticate, the client request includes an API ID to identify who the caller is and also includes an signature of a specified part of the message that includes things like the HTTP method, the API ID, a date value and some other header values, like maybe content-type. What data to include in the string to sign is up to you in your implementation, but the client and server must create and sign the same strings for the authentication to work. The signature is created by doing an hmac hash of the string using a shared secret.

On the server side, you use the API ID to retrieve the shared secret (possibly from a database or the filesystem) and perform the same hash on the request. If the hmac values match then you've authenticated the request. To prevent playback attacks, the date is included in the signed part of the request and must be within a certain window of the server's current time. For example, you might reject the request if the timestamp is more than 30 seconds old.

To enable a new user of your API, you generate a new API ID and shared secret. You give both of those to your API user and you store them for look up in your database or filesystem. The user must sign the requests with the shared secret and include the ID in the request.

The Hawk strategy provides much of this functionality, but we decided to roll our own hmac strategy.

Answer 2

Because you say that the user info endpoint returns active directory name, I assume you're on the Windows platform.

If so, why not use Windows integrated authentication (Kerberos) to authenticate your users without asking them for credentials? This will only work within your active directory domain, but is completely transparent to your service.

You can still call the user info endpoint and verify that the info it returns is for the same user that is calling your REST service.

If you need to call services that do not support Windows integrated auth, you could generate a security token (sign it to guarantee integrity) and make the other services trust this token.