Wiki

Clone wiki

rest-api-blueprint / AuthenticationScheme

Authentication scheme

There are many different authentication schemes around.

The following seem uncontroversial and sound:

  1. always use https unless particular usage affects performance too much
  2. support multiple authentications (with different capabilities) per user-account
  3. support remotely revoking access
  4. leverage a standard or common approach (don't implement something bespoke, even if "just" a variation)

Some possible approaches for handling authentication are:

  • Basic Auth - easy but sends secret, vulnerable to replay, and does not allow remote revokes
  • Hash URL, HTTP Date Header, and message body - e.g. as used by Amazon
  • OAuth 1.0a - e.g. LinkedIn, Twitter, Dropbox
  • OAuth 2.0 - e.g. Salesforce, github, Facebook, Google APIs
  • Tokens - e.g. safedrop, ge.tt (app does not store password)
  • Mozilla's Persona (was BrowserID) - new
  • OpenID connect
  • Client SSL - not very common

Beware of a potential performance issue when using a signature/encryption on large amounts of data (e.g. when POSTing/PUTing large message body). This is not just a danger of HTTPS, but also the AWS approach and OAuth 1.0a.

After much deliberation, the final choice is OAuth 2.0 because it is now mainstream, with many well known implementations (see above), is simpler then OAuth 1.0a, and avoids additional cryptography by just using HTTPS. Although the obvious choice, beware of some dangers of "bearer tokens" e.g. when not enforcing valid client certificates.

Primary source on OAuth 2.0 and Bearer tokens

Well known OAuth2 implementations

Discussions on OAuth 2.0

See also the handy:

OAuth 1.0a references

Other references

Updated