What is an API token

Question

I'm trying to work out the best way to handle user authentication for my mobile application (iOS & Android) and API (PHP).

From what I've researched the options are:

Basic auth over HTTPS - Check username/password of the user for every request.

Sessions - Send a session ID with each request; server maintains state. So app sends username/password and server checks for a logged in user on subsequent requests, just like my website does.

API tokens - Mobile app sends username/password and receives a token back, then appends this to subsequent requests. Token stored in DB and checked on each request.

I'm guessing my explanation of API tokens is incorrect as they seem identical to sessions because I store session ID's in the DB.

1. Could my explanation of API tokens be corrected. What are they for? How do they differ to session ID's?
2. What are the advantages of API tokens?
3. Is oAuth (if we were to simplify its uses) just a protocol for creating "API tokens"?

Solution

I'm no expert but I'll give you a couple of cents I've picked up:

1) API Tokens is a bit of a general term. Usually an API token is a unique identifier of an application requesting access to your service. Your service would generate an API token for the application to use when requesting your service. You can then match the token they provide to the one you store in order to authenticate.

A session id can be used but its purpose is different to the API token. The session id is not a form of authentication but rather a result of authorisation. Typically a session is established once a user has been authorised to use a resource (such as your service). Therefore a session id is created when a user is granted access to a resource. An API token is the form of authentication similar to a username/password.

2) API tokens are a replacement to sending some username/password combination over HTTP which is not secure. However the problem still exists that someone could take and use the API token instead.

3) In a way yes. It's a method for keeping API tokens "fresh". Instead of passing around the same API token you request an access token when you want to use a service. The OAuth 2.0 steps are as follows:
   a) Request sent to service with credentials of some kind
   b) Successful response returns a code
   c) Another request to service is made with the code
   d) Successful response returns the access token for signing each API request from then until finish.

A lot of the bigger service providers use OAuth 2.0 at the moment. It's not a perfect solution but it's probably the most secure, wide-spread, API security method used at the moment.

Comments

[paul]

Could you elaborate on "The session id is not a form of authentication but rather a result of authorisation."?

[David Normington]

Updated my answer, in short - The session id isn't a form of authentication, the API token is.

[paul]

Are you saying an API key just identifies requests coming from my app and is nothing to do with a user logging in via the app? Because from what I've read my API should be stateless and not use sessions.

[David Normington]

That's correct. The API token is passed in each request to the service from the app, so that the service knows who is requesting the resource. I don't recommend using sessions either, you asked ;)

[paul]

ok, so I'll have a token to identify requests are coming from my app and not another. But what should I use instead of sessions?

[David Normington]

I think I've confused us both. For your app you can use Basic HTTP authentication with sessions on the server side for persistance. Make sure the authentication is done over HTTPS for security. Edit: You can use API tokens to check the requester and user authentication but I don't think this is what you are looking for.

[paul]

yes I'm confused! Ok forgetting about where the requests are coming from for now; Android app opens and requests a username and password from the User and sends them using basic HTTP auth over SSL, subsequent requests also send the username and password. That's one method. So where does oAuth/tokens come into this if I didn't want to opt for the above basic auth method?

[David Normington]

OAuth is used more for other applications wishing to access your server, not the user land. You could use OAuth to log the user in via their twitter/facebook/another application account. The user is always going to have to give some form of input to tell the app who they are, this is the username/password combo. You can either send that once and then the server returns a token which you can then use for each subsequent request.

[paul]

ok thanks but that brings me back to my original question unfortunately: I don't understand the difference between A: sending a username and password initially and sending the session ID on subsequent requests (sessions) and B: sending a username and password initially and sending a token on subsequent requests (token)

[paul]

Also you said: "You can use API tokens to check the requester and user authentication but I don't think this is what you are looking for". Actually I think that is what I'm looking for if you mean they can both be achieved using tokens?

[David Normington]

Check this: stackoverflow.com/questions/17748868/session-id-vs-token for clarification. Also this: stackoverflow.com/questions/14003334/…

[paul]

Thanks for your replies, if possible it would be great to get an explanation of how "You can use API tokens to check the requester and user authentication.." because I think that is what i'm looking for