Authentication Techniques for APIs
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGH
1
HTTP Basic AuthStateless Session CookieJWTStateful Session CookieRandom TokenFull Request SignatureOAuth
2
DescriptionPass username and password with every requestSigned or encrypted cookie with user information. Usually handled by web framework.Signed or encrypted user info in an encoded json string. Handled by well tested libraries in every languageStandard session cookie, supported by most web frameworks and browsers.A strong, secure random token that does not have any data in it, and cannot be guessed. This is equivalent to session id.Popularized by AWS authentication.

Shared secret between server and client. Client signs the complete request using the shared secret, server verifies it.

See http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html

Only use this when you have three parties - you, your users, and third party app developers that need your user data.
If you don't have third party developers, OAuth is overkill
3
When to useFor internal APIs that are used from server side only, and are low-value.If you are building a web application only, and your framework supports it, and you do not have a distributed cache like redis/memcached. Don't implement this on your own.Mobile, Web, Server side apps. Only if you are okay to forego revocation and inactivity based timeout.If you are building a web application only, and can store sessions in database or a distributed cacheFor web and mobile apps when you already have a distributed cache like redis/memcached.
For server side apps, prefer JWT with per-request token.
Only for server side applications when you provide your clients a library to manage the cryptography, and only if you are concerned about replay attacks.

In practice, using JWT for every request, and including the url and key request parameters in the JWT achieves most of the benefits of this approach without implementing the complex canonicalization algorithm
Only if you have external third party developers who want user specific data, and you need permission from your users before sharing their data with the third party.

For anything else, OAuth is overkill.
4
Where is data stored?Server side. The username is passed in the request, the server validates it using the provided password, and then looks up whatever information it wants from it's database.In the cookieIn the tokenStored server side either in memory or in database or in distributed cache or in file system.Stored server side either in memory or in database or in distributed cache or in file system.Server side. The "userid" is passed in the request, the signature tells the server it is indeed that user. The server can then look up whatever information it wants from it's database.TBD
5
ExpiryNot relevant. Upto the server to manageStored in the cookieStored in the tokenStored server sideStored server sidePassed in the request, and usually valid for a very short time only.
6
Use Crypto?No CryptographyYes, but usually handled by web frameworkYes, but usually handled by mature libraryNo CryptographyNo CryptographyYes.
Outside of AWS libraries, there isn't a good standard implementation, so it will be painful to use if you don't provide client libraries
7
Inactivity based timeoutNot relevant. Don't use this technique for web based clientsServer has to overwrite the cookie with every request, setting a new expiry time. If the framework doesn't handle this alread, this can be painfulPainful.
You have to use refresh tokens, which is added work for the client.
You can maintain a last_seen_at flag in a database/cache, and use that to expire, but then you lose the benefits of being stateless
Yes.
Easily handled out of the box in every web framework
Yes.
With every request, increment the timeout on the server side.
Doesn't make sense.
This approach only makes sense for server side applications, and in such applications inactivity based timeout does not make sense
8
RevocationNot relevant. Don't use this technique for web based clientsPainful.
You have to maintain a separte revocation list in a distributed store. Again, you lose the benefits of being stateless
Painful.
You have to maintain a separate revocation list in a distributed store. Again, you lose the benefits of being stateless.
Possible, but exact capabilities depends on web frameworkYes.
Simply delete the session data on the server side, and next request will be considered unauthenticated.
Yes,
The server can easily deny the request.
9
Browser: StorageNot relevant. Don't use this technique for web based clientsImplicit.
Browser handles this automatically, no effort on part of the programmer
Explicit.
Programmer has to store the token somewhere. Usually sessionStorage or localStorage.
Implicit.
Browser handles this automatically, no effort on part of the programmer
Explicit.
Programmer has to store the token somewhere. Usually sessionStorage or localStorage.
Not applicable.
This technique is not suitable for web applications.
10
Passing CredentialsPassed in Authorization header

Example:

Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

Username and password are NOT encrypted
As cookie. Browser automatically sends this to the serverAs request header -
Authorization: Bearer <token>

Programmer explicitly passes this with every request
As cookie. Browser automatically sends this to the serverAs request header -
Authorization: Bearer <token>

Programmer explicitly passes this with every request
Passed in the Authorization header, but instead of "bearer", it will be some other custom scheme. AWS uses AWS4-HMAC-SHA256.

Example:

Authorization: AWS4-HMAC-SHA256 Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7

Programmer explicitly passes this with every request
11
Browser: CSRF VulnerabilitiesVulnerable. Do not use basic authentication for web apps, unless it is a low value internal web applicationVulnerable.
Programmers need to be careful to prevent CSRF
Not vulnerable, because token is passed explicity as a request headerVulnerable.
Programmers need to be careful to prevent CSRF
Not vulnerable, because token is passed explicity as a request headerNot applicable.
This technique is not suitable for web applications.
12
Native mobile appsDon't use basic authentication. Mobile apps cannot store the credentials safely, and users will not want to enter credentials for every requestNative mobile apps will find session based auth painful. Avoid session based auth if mobile apps are expected to use APIMobile app users expect to login just once, and don't ever login again. JWT with a long expiry can work, but a better strategy is to use a secure random token with no information in it.Native mobile apps will find session based auth painful. Avoid session based auth if mobile apps are expected to use APICreate the random token during first installation/login, and use that token throughout the life of the app.Not applicable.
This technique is not suitable for web applications - because the mobile app cannot keep secrets.
13
Server side appsIf you use HTTPS, then basic authentication is a good choice for server side only applications. It is the easiest to get started, and is well supported by clients and server frameworksServer side apps will find session based auth painful. Avoid if server side apps are expected to use APICreate a private-public key pair, and let the client create the JWT with the private key and the server validate it using the public key.
Alternatively, maintain a shared secret and use that to create the JWT.
Prefer private/public key pair instead of shared secret.
Create JWT on every request, and keep expiry very low.
Server side apps will find session based auth painful. Avoid if server side apps are expected to use APIThis becomes similar to an API key that is passed by the client. Replay attacks are possible if someone gets the API key.
For server to server apps, prefer JWT with public/private key pair
This is a preferred approach for server side applications where higher security is needed.
In principle, it is similar to JWT with shared keys, except that in this approach everything is signed - the url, the parameters, the request headers and the request body.
14
Replay AttacksDefinitely possible.PossiblePossible only if the expiry is high. If every request generates a new JWT (like in case of server side apps), then replay attacks becomes very difficult.PossiblePossibleBecause everything is signed, this makes replay attacks impossible
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Sheet1
 
 
Main menu