phpandroidiosauthentication

What is an API token


I'm trying to work out the best way to handle user authentication for my mobile application (iOS and 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.