HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature

ful Session Cookie Random Token Full Request Signature OAuth

Description Pass username and password Signed or encrypted cookie Signed or encrypted user info Standard session cookie, A strong, secure random token Popularized by AWS Only use this when you have
with every request with user information. Usually in an encoded json string. supported by most web that does not have any data in authentication. three parties - you, your users,
handled by web framework. Handled by well tested frameworks and browsers. it, and cannot be guessed. and third party app developers
libraries in every language This is equivalent to session Shared secret between server that need your user data.
id. and client. Client signs the If you don't have third party
complete request using the developers, OAuth is overkill
shared secret, server verifies
it.

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

When to use For internal APIs that are used If you are building a web Mobile, Web, Server side If you are building a web For web and mobile apps Only for server side Only if you have external third
from server side only, and are application only, and your apps. Only if you are okay to application only, and can store when you already have a applications when you provide party developers who want
low-value. framework supports it, and you forego revocation and sessions in database or a distributed cache like your clients a library to user specific data, and you
do not have a distributed inactivity based timeout. distributed cache redis/memcached. manage the cryptography, and need permission from your
cache like redis/memcached. For server side apps, prefer only if you are concerned users before sharing their data
Don't implement this on your JWT with per-request token. about replay attacks. with the third party.
own.
In practice, using JWT for For anything else, OAuth is
every request, and including overkill.
the url and key request
parameters in the JWT
achieves most of the benefits
of this approach without
implementing the complex
canonicalization algorithm
Where is data Server side. The username is In the cookie In the token Stored server side either in Stored server side either in Server side. The "userid" is TBD
stored? passed in the request, the memory or in database or in memory or in database or in passed in the request, the
server validates it using the distributed cache or in file distributed cache or in file signature tells the server it is
provided password, and then system. system. indeed that user. The server
looks up whatever information can then look up whatever
it wants from it's database. information it wants from it's
database.
Expiry Not relevant. Upto the server Stored in the cookie Stored in the token Stored server side Stored server side Passed in the request, and
to manage usually valid for a very short
time only.
Use Crypto? No Cryptography Yes, but usually handled by Yes, but usually handled by No Cryptography No Cryptography Yes.
web framework mature library 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
Inactivity based Not relevant. Don't use this Server has to overwrite the Painful. Yes. Yes. Doesn't make sense.
timeout technique for web based cookie with every request, You have to use refresh Easily handled out of the box With every request, increment This approach only makes
clients setting a new expiry time. If tokens, which is added work in every web framework the timeout on the server side. sense for server side
the framework doesn't handle for the client. applications, and in such
this alread, this can be painful You can maintain a applications inactivity based
last_seen_at flag in a timeout does not make sense
database/cache, and use that
to expire, but then you lose the
benefits of being stateless
Revocation Not relevant. Don't use this Painful. Painful. Possible, but exact capabilities Yes. Yes,
technique for web based You have to maintain a You have to maintain a depends on web framework Simply delete the session data The server can easily deny the
clients separte revocation list in a separate revocation list in a on the server side, and next request.
distributed store. Again, you distributed store. Again, you request will be considered
lose the benefits of being lose the benefits of being unauthenticated.
stateless stateless.
Browser: Not relevant. Don't use this Implicit. Explicit. Implicit. Explicit. Not applicable.
Storage technique for web based Browser handles this Programmer has to store the Browser handles this Programmer has to store the This technique is not suitable
clients automatically, no effort on part token somewhere. Usually automatically, no effort on part token somewhere. Usually for web applications.
of the programmer sessionStorage or of the programmer sessionStorage or
localStorage. localStorage.
 HTTP Basic Auth
Passing Passed in Authorization
Credentials header
Example:
Authorization: Basic
QWxhZGRpbjpPcGVuU2VzY
W1l
Username and password are
NOT encrypted
Browser: CSRF Vulnerable. Do not use basic
Vulnerabilities authentication for web apps,
unless it is a low value internal careful to prevent CSRF
web application
Native mobile Don't use basic authentication.
apps Mobile apps cannot store the
credentials safely, and users
will not want to enter
credentials for every request
Server side If you use HTTPS, then basic
apps 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 frameworks
Replay Attacks Definitely possible.
Stateless Session Cookie JWT
As cookie. Browser
automatically sends this to the Authorization: Bearer <token> automatically sends this to the
server
Vulnerable.
Programmers need to be
Native mobile apps will find
session based auth painful.
Avoid session based auth if
mobile apps are expected to
use API
Server side apps will find
session based auth painful.
Avoid if server side apps are
expected to use API
Possible
Stateful Session Cookie Random Token Full Request Signature OAuth
As request header - As cookie. Browser As request header - Passed in the Authorization
Authorization: Bearer <token> header, but instead of
server "bearer", it will be some other
Programmer explicitly passes Programmer explicitly passes custom scheme. AWS uses
this with every request this with every request AWS4-HMAC-SHA256.
Example:
Authorization: AWS4-HMAC-
SHA256
Credential=AKIDEXAMPLE/20
150830/us-east-
1/iam/aws4_request,
SignedHeaders=content-type;
host;x-amz-date,
Signature=5d672d79c15b131
62d9279b0855cfba6789a8edb
4c82c400e06b5924a6f2b5d7
Programmer explicitly passes
this with every request
Not vulnerable, because token Vulnerable. Not vulnerable, because token Not applicable.
is passed explicity as a Programmers need to be is passed explicity as a This technique is not suitable
request header careful to prevent CSRF request header for web applications.
Mobile app users expect to Native mobile apps will find Create the random token Not applicable.
login just once, and don't ever session based auth painful. during first installation/login, This technique is not suitable
login again. JWT with a long Avoid session based auth if and use that token throughout for web applications - because
expiry can work, but a better mobile apps are expected to the life of the app. the mobile app cannot keep
strategy is to use a secure use API secrets.
random token with no
information in it.
Create a private-public key Server side apps will find This becomes similar to an This is a preferred approach
pair, and let the client create session based auth painful. API key that is passed by the for server side applications
the JWT with the private key Avoid if server side apps are client. Replay attacks are where higher security is
and the server validate it using expected to use API possible if someone gets the needed.
the public key. API key. In principle, it is similar to JWT
Alternatively, maintain a For server to server apps, with shared keys, except that
shared secret and use that to prefer JWT with public/private in this approach everything is
create the JWT. key pair signed - the url, the
Prefer private/public key pair parameters, the request
instead of shared secret. headers and the request body.
Create JWT on every request,
and keep expiry very low.
Possible only if the expiry is Possible Possible Because everything is signed,
high. If every request this makes replay attacks
generates a new JWT (like in impossible
case of server side apps), then
replay attacks becomes very
difficult.
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth
HTTP Basic Auth Stateless Session Cookie JWT Stateful Session Cookie Random Token Full Request Signature OAuth