RESTful API authentication design

Question

A bit of a conceptual question: I am designing a private RESTful API that will be used by iOS and Android apps.

I am using JWT.

I have an api_users table that allows access to the the API itself.

I also have a users table for individual user login using the apps (ie an individual's e-mail and password).

So here's where I'm confused:

1. Should I ditch the api_users table and have a single authentication endpoint for users , or
2. Should the login process require both the api_users ' and the users ' credentials for a valid JWT to be returned; or
3. Should I have two separate auth endpoints (one for api_users and another for the regular users ).

If I take the third route, in keeping with RESTful (stateless) design, would I need a second JWT to keep track of what user is requesting my API?

Thank you all!

Answer 1

You should not have two tables that represent two different types of users (eg API users / app users). One table is sufficient. In terms of keeping track of what user is requesting your API your logs should be sufficient unless you need to store and present additional metrics on the front-end or you wish to limit access (throttling / one request per user at a time) and your framework does not manage this. When your users authenticate with your app they will now be issued with a JWT token that can be used to make API calls.

Answer 2

A RESTful API shouldn't have a login process, that requires maintaining state. You'll authenticate by providing a valid JWT packet with each request, and in order to create the packet, you'll need a token and some sort of unique account identifier. You will not need any password to create the JWT packet.

Regarding getting a token, you have two options:

• You can create an endpoint that requires the main account user/pass (rather than JWT) and then hands out a new token. Then you use that token on subsequent JWT-based requests. This is a simpler design but there are two main downsides to this method:
  • You don't have any control over tokens, so all your logging and throttling has to be done at the user level.
  • Using the API requires you to know the password for the main account.
• You can design your site's front end to allow logged-in users to create/manage an arbitrary number of API tokens. This has a number of advantages:
  • Using the API doesn't require knowing the password for the main account. This allows users to hand out tokens to 3rd parties (like linked apps) without giving up full access to their account.
  • Each token can be strictly controlled. Eg, you can log/throttle them individually, and you can revoke one without affecting anybody else.

In either case, you'll need a table for users and another table for tokens.