Home / Web programming, webdev / Authentication methods edit
Try Documentalist, my app that offers fast, offline access to 190+ programmer API docs.

  • HTTP Basic Auth
    What. Pass username and password with every request.
    When to use. For internal APIs that are used from server side only, and are low-value.
    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.
    Expiry. Not relevant. Up to the server to manage.
    Use Crypto? No Cryptography
    Inactivity based timeout. Not relevant. Don't use this technique for web based clients
    Revocation. Not relevant. Don't use this technique for web based clients
    Browser Storage. Not relevant. Don't use this technique for web based clients
    Passing Credentials. Passed in Authorization header
    Example:
    Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
    Username and password are NOT encrypted
    Browser: CSRF Vulnerabilities. Vulnerable. Do not use basic authentication for web apps, unless it is a low value internal web application
    Native mobile apps. Don't use basic authentication. Mobile apps cannot store the credentials safely, and users will not want to enter credentials for every request.
    Server side apps. If 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 frameworks.
    Replay Attacks. Definitely possible.
  • Stateless Session Cookie
    What. Signed or encrypted cookie with user information. Usually handled by web framework.
    When to use. 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.
    Where is data stored? In the cookie
    Expiry. Stored in the cookie
    Use Crypto? Yes, but usually handled by mature library
    Inactivity based timeout. Server has to overwrite the cookie with every request, setting a new expiry time. If the framework doesn't handle this already, this can be painful
    Revocation. Painful. You have to maintain a separate revocation list in a distributed store. Again, you lose the benefits of being stateless
    Browser Storage. Implicit. Browser handles this automatically, no effort on part of the programmer
    Passing Credentials. As cookie. Browser automatically sends this to the server
    Browser: CSRF Vulnerabilities. Vulnerable. Programmers need to be careful to prevent CSRF
    Native mobile apps. Native mobile apps will find session based auth painful. Avoid session based auth if mobile apps are expected to use API
    Server side apps. Server side apps will find session based auth painful. Avoid if server side apps are expected to use API
    Replay Attacks. Possible
  • JWT
    What. Signed or encrypted user info in an encoded json string. Handled by well tested libraries in every language
    When to use. Mobile, Web, Server side apps. Only if you are okay to forego revocation and inactivity based timeout.
    Where is data stored? In the token.
    Expiry. Stored in the token
    Use Crypto? Yes, but usually handled by mature library
    Inactivity based timeout. Painful. 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
    Revocation. Painful. You have to maintain a separate revocation list in a distributed store. Again, you lose the benefits of being stateless.
    Browser Storage. Explicit. Programmer has to store the token somewhere. Usually sessionStorage or localStorage.
    Passing Credentials. As request header -
    Authorization: Bearer <token>
    Programmer explicitly passes this with every request
    Browser: CSRF Vulnerabilities. Not vulnerable, because token is passed explicitly as a request header
    Native mobile apps. Mobile 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.
    Server side apps. Create 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.
    Replay Attacks. Possible 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.
  • Stateful Session Cookie
    What. Standard session cookie, supported by most web frameworks and browsers.
    When to use. If you are building a web application only, and can store sessions in database or a distributed cache.
    Where is data stored? Stored server side either in memory or in database or in distributed cache or in file system.
    Expiry. Stored server side
    Use Crypto? No Cryptography
    Inactivity based timeout. Yes. Easily handled out of the box in every web framework
    Revocation. Possible, but exact capabilities depends on web framework
    Browser Storage. Implicit. Browser handles this automatically, no effort on part of the programmer
    Passing Credentials. As cookie. Browser automatically sends this to the server
    Browser: CSRF Vulnerabilities. Vulnerable. Programmers need to be careful to prevent CSRF
    Native mobile apps. Native mobile apps will find session based auth painful. Avoid session based auth if mobile apps are expected to use API
    Server side apps. Server side apps will find session based auth painful. Avoid if server side apps are expected to use API
    Replay Attacks. Possible
  • Random Token
    What. A strong, secure random token that does not have any data in it, and cannot be guessed. This is equivalent to session id.
    When to use. For web and mobile apps when you already have a distributed cache like redis/memcached. For server side apps, prefer JWT with per-request token.
    Where is data stored? Stored server side either in memory or in database or in distributed cache or in file system.
    Expiry. Stored server side
    Use Crypto? No Cryptography
    Inactivity based timeout. Yes. With every request, increment the timeout on the server side.
    Revocation. Yes. Simply delete the session data on the server side, and next request will be considered unauthenticated.
    Browser Storage. Explicit. Programmer has to store the token somewhere. Usually sessionStorage or localStorage.
    Passing Credentials. As request header -
    Authorization: Bearer <token>
    Programmer explicitly passes this with every request
    Browser: CSRF Vulnerabilities. Not vulnerable, because token is passed explicitly as a request header
    Native mobile apps. Create the random token during first installation/login, and use that token throughout the life of the app.
    Server side apps. This 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
    Replay Attacks. Possible
  • Full Request Signature
    What. 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
    When to use. 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
    Where is data stored? 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.
    Expiry. Passed in the request, and usually valid for a very short time only.
    Use Crypto? Yes. 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 timeout. Doesn't make sense.
    This approach only makes sense for server side applications, and in such applications inactivity based timeout does not make sense
    Revocation. Yes. The server can easily deny the request.
    Browser Storage. Not applicable. This technique is not suitable for web applications.
    Passing Credentials. 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
    Browser: CSRF Vulnerabilities. Not applicable. This technique is not suitable for web applications.
    Native mobile apps. Not applicable. This technique is not suitable for web applications - because the mobile app cannot keep secrets.
    Server side apps. 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.
    Replay Attacks. Because everything is signed, this makes replay attacks impossible
  • Oauth
    What. 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
    When to use. 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.
    Where is data stored?
    Expiry.
    Use Crypto?
    Inactivity based timeout.
    Revocation.
    Browser Storage.
    Passing Credentials.
    Browser: CSRF Vulnerabilities.
    Native mobile apps.
    Server side apps.
    Replay Attacks.
csrf:

Feedback about page:

Feedback:
Optional: your email if you want me to get back to you:

Share on        

Need fast, offline access to 190+ programmer API docs? Try my app Documentalist for Windows