Implicit vs Explicit Authentication in Browser-based Applications

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?
Whenever the application code (JavaScript in that case) has to send the credential explicitly – typically on the Authorization header (and sometimes also as a query string). Using OAuth 2.0 implicit flow and access tokens in JS apps is a common example. Strictly speaking the browser does not know anything about the credential and thus would not send it automatically.


  • 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.

This entry was posted in WebAPI. Bookmark the permalink.

6 Responses to Implicit vs Explicit Authentication in Browser-based Applications

  1. Alexey Auslender says:

    Thanks for grate explanation,just small remark you noticed that No CSRF is disadvantage in case of explicit authentication ,I guess it was accidentally.

  2. smwikipedia says:

    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.

  3. Aakash says:

    “Domain bound – only “clients” from the same domain as the “server” will be able to communicate.” – This is not really a disadvantage.

    • Alexey Aouslender says:

      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..).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s