I got the idea for this post from my good friend Pedro Felix – I hope I don’t steal his thunder (I am sure I won’t – since he is much more elaborate than I am) – but when I saw his tweet this morning, I had to write this post.
When teaching web API security, Brock and I often use the term implicit vs explicit authentication. I don’t think these are standard terms – so here’s the explanation.
What’s implicit authentication?
Browser built-in mechanisms like Basic, Windows, Digest authentication, client certificates and cookies. Once established for a certain domain, the browser implicitly sends the credential along automatically.
Advantage: It just works. Once the browser has authenticated the user (or the cookie is set) – no special code is necessary
- No control. The browser will send the credential regardless which application makes the request to the “authenticated domain”. CSRF is the result of that.
- Domain bound – only “clients” from the same domain as the “server” will be able to communicate.
What’s explicit authentication?
- Full control over when the credential is send.
- No CSRF.
- Not bound to a domain.
- Custom code necessary.
- Access tokens need to be managed by the JS app (and don’t have built-in protection features like httpOnly cookies) which make them interesting targets for other types of attacks (CSP can help here).
Summary: Implicit authentication works great for server-side web applications that live on a single domain. CSRF is well understood and frameworks typically have built-in countermeasures. Explicit authentication is recommended for web APIs. Anti CSRF is harder here, and clients and APIs are often spread across domains which makes cookies a no go.