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.
Thanks for grate explanation,just small remark you noticed that No CSRF is disadvantage in case of explicit authentication ,I guess it was accidentally.
At the end of the article, when you say “and clients and APIs are often spread across domains which makes cookies a no go”. I don’t quite understand “clients” here. I think it is only “APIs” that are deployed to multiple domains is relevant.
well – it basically means that client and API live in separate domains.
“Domain bound – only “clients” from the same domain as the “server” will be able to communicate.” – This is not really a disadvantage.
From the modern application architecture point of view ,this is definitely disadvantage.You want to consume your back-end from different clients technologies (native ,browser based ant ctr..).