This post is part of a multi-part series. It builds on the first post, where I describe the framework we will use to evaluate authentication schemes. If you have not, it is probably a good idea to read it now (hint).
Here is where we are.
- I. What to look for in an authentication scheme?
- II. Evaluation of standard authentication schemes
- III. Cheatsheet and closing thoughts
III. Cheatsheet and closing thoughts
What are my options?
Up till this point, we covered 6 authentication schemes. You now know their background, how they work and the pros and cons of each. Wouldn’t it be nice to see all that on a single page?
I got you covered. Here is a cheatsheet compiled from the previous posts.
The Web API Authentication Cheatsheet
The cheatsheet contains a brief summary of the 6 authentication schemes covered by this series. It is a great overview which allows you to quickly compare and contrast different solutions. Check it out!
Okay, how do I choose?
Now we are getting somewhere. This is a great question. To be able to answer it, first, you must know your use cases. Here are some questions to help you better understand your requirements.
- Who are the players? Browser-server or server-server?
- Do you need full session management support?
- Do you have elevated security requirements?
- Are there particular use-cases?
- Do you have access to the underlying infrastructure configuration?
Reading these questions, you may immediately think of a flowchart. Yeah, I did too. Answer a few questions and arrive at an authentication scheme perfect for your use-case. Sounds great, eh?
Unfortunately, it isn’t that simple; there are too many variables. Instead, below you will find some categories and the winner in each with a short supporting argument. If you want to learn more about a scheme, check out its article.
Simplest
Without argument, the simplest of schemes is HTTP Basic. It is widely supported and has been around since 1999! It works well to protect read-only resources on the frontend and also performs okay on the backend for securing APIs.
Value-deal for frontend
The winner here is Cookies. They are the de-facto authentication standard between the browser and the server, a.k.a the frontend. Using cookies is very cheap, and they provide lots of security features out-of-the-box: full-featured session management, protection from XSS, CSRF protection (hint: SameSite flag).
Most versatile
This award goes to Bearer tokens. They can be used on the frontend and the backend equally easily. Our favorite delegation protocol, OAuth, also greatly relies on them. There is also JWT, the de-facto standard for self-describing tokens.
High-end for backend
If you are looking for a little extra on the backend, you should go with TLS Client certificates or Signature schemes. Both provide a high degree of protection, even from active network attackers. You pay for this security with the relative complexity of these systems. It is, after all, a tradeoff.
Most secure
The absolute best you can do is to combine the two winners of the previous category. Having TLS Client Certificates and HTTP Signatures deployed together is possible. This provides a well-designed defense-in-depth solution, but not without its costs. Think twice before committing to this setup.
Most exotic
Undoubtedly, this is HTTP Digest. It packs tons of features, most of which are not supported, even by modern implementations. It is a competent scheme but failed to reach widespread adaptation. Use it when you need better security than Basic but do not have a stronger alternative.
Options everywhere, choose wisely
Navigating the security field isn't always easy. Simple uncovering the possibilities can be overwhelming. Let SCADEMY help you, sign up for one of our Web Application Security courses.
Closing thoughts
Today, you have lots of choices regarding authentication. The world is changing, and we have done well to come up with new solutions to our modern use-cases. There is no clear winner, it all depends on what you are doing and what your constraints are.
Security is a tradeoff, and you should be able to make smart tradeoffs. This guide empowers you to do just that. You are now able to choose your next authentication scheme confidently.
Have no mistake, in time a new scheme may come along. Spend some time studying it and add it to your toolset.
Remember, to make smart tradeoffs you need to have a certain level of knowledge. Don’t worry; I got your back!
Take a look around the site and don’t forget to sign up to the newsletter (upper right corner of the page).
Spot a mistake in reasoning? Have a different opinion? Sound off in the comments!