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

Disadvantage:

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

Advantage:

  • Full control over when the credential is send.
  • No CSRF.
  • Not bound to a domain.

Disadvantages:

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

Posted in WebAPI | 2 Comments

IdentityServer3 vNext

Just a quick update about some upcoming changes in IdentityServer3.

The last weeks since the 1.0.0 release in January we did mostly bug fixing, fine tuning and listening to feedback. Inevitably we found things we want to change and improve – and some of them are breaking changes.

Right now we are in the process of compiling these small and big changes to bundle them up in a 2.0.0 release, so hopefully after that we can go back into fine tuning mode without breaking anybody’s code.

Here’s a brief list of things that have/will change in 2.0.0

  • Consolidation of some validation infrastructure
    • ICustomRequestValidator signature has slightly changed
  • Support for X.509 client certificates for client authentication at the token endpoint. This resulted in a number of changes to make client validation more flexible in general
    • ClientSecret has been renamed to Secret (we will probably use the concept of secrets in more place than just the client in the future)
    • IClientSecretValidator is gone in favour of a more high level IClientValidator
  • The event service is now async (we simply missed that in 1.0)
  • The CorsPolicy has been replaced by a CORS policy service – along with configurable CORS origins per client
  • By default clients have no access to any scopes. You need to configure the allowed scopes (or override by setting the new AllowAccessToAllScopes client flag)

Probable the biggest change is the fact that we renamed the nuget package to simply IdentityServer3. We decided to remove the thinktecture registered trademark from the OSS project altogether (including the namespaces – so that’s another breaking change).

So in the future all you need to do is:

install-package IdentityServer3 (-pre for the time being)

The dev branch on github is now on 2.0.0 and we published a beta package to nuget so you can have a look (in addition to our myget dev feed):

https://www.nuget.org/packages/IdentityServer3/2.0.0-beta1

Feedback is welcome!

Posted in .NET Security, ASP.NET, IdentityServer, OAuth, OpenID Connect, OWIN, WebAPI | Leave a comment

.NET Foundation Advisory Council

I have been invited to join the .NET Foundation advisory council – looking forward to it!

http://www.dotnetfoundation.org/blog/welcoming-the-newly-minted-advisory-net-foundation-advisory-council-members

Posted in .NET Security, ASP.NET, IdentityModel, IdentityServer, WebAPI | 2 Comments

IdentityServer3 1.0.0

Today is a big day for us! Brock and I started working on the next generation of IdentityServer over 14 months ago. In fact – I remember exactly how I created the very first file (constants.cs) somewhere in the Swiss Alps and was hunting for internet connection to do a check-in (much to the dislike of my family).

1690 commits later it is time to recap what we did, why we did it – and where we are now.

Having spent a considerable amount of time in the WS*/SAML world, it became more and more apparent that these technologies are not a good match for the modern types of applications that we (and our customers) like to build. These types of applications are pretty much a combination of web and native UIs combined with web APIs. Security protocols need to be API, HTTP and mobile friendly, and we need authentication, API access and identity delegation as first class citizens.

We had two options – either try to retrofit the new protocols into the old WS* architecture (like so many commercial products do) or start from scratch. Since we also had a number of other high priority design goals for the new version we decided to start from scratch.

Some of the highlights of IdentityServer3 (at least in our opinion) are:

Support for the modern security stack
OpenID Connect and OAuth2 that is. These two protocols in combination are the perfect match to build the modern applications we had in mind. OAuth2 is used to manage access (and access control) from clients to APIs for both trusted subsystem and identity delegation systems. OpenID Connect is the extension to OAuth2 for implementing rich authentication and single sign-on scenarios for any application type.

Hosting
We wanted to be much more flexible in our hosting scenarios – IIS vs self-hosting, Windows vs Linux, ASP.NET vCurrent vs vNext, Embedded into the application vs separate standalone vs separate web farm vs cloud – you name it. Regardless which hosting environment you choose – IdentityServer is always the same.

Flexibility and Extensibility
IdentityServer2 always had a dependency on a database. The past years taught us that there are many situations where this is not appropriate. In the new version everything is code first and abstracted behind interfaces. Everything can be done in memory and no persistence store is required. We have an optional extension that uses Entity Framework for persistence – but this is up to you.

Another issue we had in the past was that there were too many situations where one had to change the core source code to implement some custom workflow. In IdentityServer3 we think we did a good job in anticipating the typical (and not so typical) modifications and baked them right into the core runtime as extensibility points. So far this has worked out really well.

Framework vs Server
As mentioned above – IdentityServer3 is all about customization and extensibility. The developer is in the centre and we give him lots of freedom in changing almost any aspect of the workflow. This is the big difference to many commercial off the shelf products.

Right from the start we used the term “STS Framework” rather than a “Server” and up to today we don’t even have an admin UI for managing the server configuration. We (and most people we spoke to) were absolutely fine doing all of that in code and in their custom configuration system. That said – we have an admin service and UI in the works that will be released soon – but again this is totally optional.

Brock and I just recently spoke to Carl and Richard about these design goals on .NET Rocks.

Where to go?
To accommodate the new versioning scheme (we switched to semver) and the componentized architecture we changed both the GitHub organization and repo names as well as the Nuget package names. The new organization can be found here and the main repo is here along with instructions on how to contribute and an issue tracker for filing bugs or giving feedback.

The new docs site gives quite a bit of background and can be found here – or you can jump directly to our samples.

If you need consulting about modern (or not so modern) security architectures in general and IdentityServer in particular – you can contact us via email at identity@leastprivilege.com or via twitter: @leastprivilege & @brocklallen.

What’s next?
We have a couple of “side projects” that complement the core IdentityServer3 – there’s IdentityManager, which we neglected a bit for the last months, and there‘s the admin service and UI (good people are working on that right now)…And there are of course new features to implement for IdentityServer – check this label and take part in the discussion.

Last but not least
The last 14 months were astounding – we got more feedback, questions, bug reports, PRs and help on IdentityServer3 than all other OSS projects we did before combined. You guys were fantastic! Thanks for your help – we hope you enjoy the result (..and keep it coming)!

Thanks!
Dominick & Brock

Posted in ASP.NET, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | 23 Comments

2014 in review

The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 530,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 23 days for that many people to see it.

Click here to see the complete report.

Posted in Uncategorized | Leave a comment

The Future of AuthorizationServer

Now that IdentityServer v3 is almost done, it makes sense to “deprecate” some of the older projects. Especially all of the functionality of AuthorizationServer is completely replaced by the IdSrv3 feature set.

AuthorizationServer is actually a pretty small and compact code base, and a relatively complete implementation of OAuth2 including a simple authorization model based on clients, applications and scopes. Also there are no major bugs (that we know about) or feature gaps.

IOW – if you want to use AS, simply make it part of your own code base and feel free to change it at will. Check the wiki for documentation.

If somebody wants to take over the project, contact me.

Posted in ASP.NET, AuthorizationServer, OAuth, WebAPI | 6 Comments

IdentityServer & IdentityManager, Updates and the .NET Foundation

It’s busy times right now but we are still on track with our release plans for IdentityServer (and IdentityManager, which will get more love once IdentityServer is done). In fact we just pushed beta 3-4 to github and nuget, which mostly contains bug fixes and merged pull requests.

The other big news is that both projects joined the .NET Foundation as part of the announcements around open sourcing .NET. Joining the Foundation provides us with a strong organizational backbone to increase the visibility and attractiveness of IdentityServer and IdentityManager to both, new users and new committers. As a current user of one of these projects, this will provide even stronger long-term safety of your investments in the use of these frameworks.

If you want to contribute to any of the projects – you are more than welcome! Please have a look at our contribution guidelines and don’t hesitate to get in touch with us!

Also big thanks to our contributors – and especially Damian Hickey and Hadi Hariri who proved this week that this whole community thing is actually working!

Posted in ASP.NET, IdentityServer, Katana, OAuth, OpenID Connect, OWIN, WebAPI | Leave a comment