Identity Server 4 is the newest iteration of IdentityServer, the popular OpenID Connect and OAuth Framework for .NET, updated and redesigned for ASP.NET Core and .NET Core. In this article we are take a quick look at why IdentityServer 4 exists, and then dive right in and create ourselves a working implementation from zero to hero.

• IdentityServer 3 vs IdentityServer 4
• Implementing IdentityServer4 on ASP.NET Core and .NET Core
• OAuth Functionality
• User Interface
• OpenID Connect
• Entity Framework Core
• ASP.NET Core Identity

IdentityServer 3 vs IdentityServer 4

A popular phrase going at the moment is 'conceptually compatible' but this rings true for Identity Server 4. The concepts are the same, it is still an OpenID Connect provider built to spec, however most of its internals and extensibility points have changed. When we integrate a client application with IdentityServer, we are not integrating to an implementation. Instead we are integrating using the OpenID Connect or OAuth specifications. This means...

Azure DocumentDB is the Platform-as-a-Service NoSQL document database available on Microsoft's cloud platform Azure. Similar to other popular document databases such as MongoDB and RavenDB, DocumentDB allows for the simple storage of entities as JSON with no enforced schema, but with the added benefit of being Platform-as-a-Service. This means that it is completely managed by Azure, with no need to manage the underlying resources and also the ability to use Azure’s impressive scalability at will. DocumentDB is hosted entirely on SSDs and is very fast, with Azure reporting a 1-2ms call completion when working within the same Azure region.

DocumentDB also has the ability to manage transactions, choose consistency levels, to use complex querying with SQL like syntax, and to use server side features, created using JavaScript, in the form of stored procedures, triggers and user defined functions.By default all documents are indexed, however this can be turned off with only document Id’s being indexed.

So I’ve just got back to my hotel from the final day of NDC Oslo 2016 and as you always end being after these things, I’m shattered. I came with the objective of finally getting some learning on ASP.NET Core (however much it may have pained me) and where better to do it at one of the biggest and most respected conferences going? Whilst I may have started off with ASP.NET Core in mind, I soon got distracted by the high quality security speakers and wide range of subjects.

I think the best write up I can give is to talk through the experience and then list the talks that I attended, making recommendations where possible about which speaker or talks you should keep an eye out for. Once the talks are uploaded to Vimeo, I can also directly link you to each one individually.

Basic Authentication is considered a bit of an anti-pattern these days, but it can still be useful in a pinch when you have limited options for integrating with APIs, third party applications or the dreaded legacy applications.

Basic Authentication should never be a recommended solution, however I have met many clients who are still running services that use it and third party applications who only support basic authentication. Some security is better than none, right? I guess that's debatable.

If you want a modern identity solution, check out Identity Server. Identity Server is a one time configuration that will allow you to create your own OAuth, OpenID Connect or WS-Federation Authentication Server (aka Identity Provider, Security Token Service, etc), that can reliably service all of your applications.

This article will cover the theory behind basic authentication, including why we shouldn't really be using it, and then look at how we can integrate it into our OWIN pipeline.

When using the WS-Federation protocol, you usually (or at least should) use certificates to sign your token, allowing the receiver to verify the contents have not been altered in transit, and for Transport Layer Security (TLS, think SSL) in order to provide privacy for network communications.

What is less common but also useful is SAML assertion encryption.This token encryption is useful when your SAML token includes claims/assertions that contain private data which might be held for a long period of time or passed around through untrusted intermediaries.

This certificate has its public key held by the Security Token Service (STS) in order to encrypt the token, and its private key held by the Relying Party in order to decrypt it.

This process is relatively well documented if you are dealing with Windows Identity Foundation (WIF) 1.0 and slightly less so with WIF 4.5, however there are currently little to no resources on how to achieve this with the latest OWIN/Katana components.