10th Anniversary

…seems that this blog is now ten years old. Who would have thought.

Posted in Uncategorized | 3 Comments

Claims-based Authentication does not exist (for crying out loud)

…as much as there is no “role-based authentication”.

Rather use “claims-based identity” or “token-based authentication”


Posted in Uncategorized | 1 Comment

100k Downloads of Thinktecture IdentityModel



Thanks for all the feedback – but keep in mind that this package is deprecated. For Web API => v2 and MVC >= 5 please use the new Thinktecture.IdentityModel.Core and family.

Posted in IdentityModel | 2 Comments

IdentityServer v3 Nuget and Self-Hosting

Thanks to Damian and Maurice we now have a build script for IdSrv3 that creates a Nuget package *and* internalizes all dependencies. So in other words you only need to reference a single package (well strictly speaking two) to self host the STS (including Autofac, Web API, various Katana components etc). Pretty cool. Thanks guys!

A picture says more than 1000 words (taken from the new self host sample in the repo).


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

Web API 2 Excel File Export With OAuth2 Implicit Flow

Originally posted on Software Engineering:

This article demonstrates how to set up a Web API 2 excel file download using OAuth2 Implicit Flow. The application requires an Authorization Server and Identity Server V2 from Thinkteckture and also the excel Media Formatter from WebApiContrib. leastprivilege.com provided a lot of blogs which helped complete this article. Thanks for those blogs. The article should help as a simple Howto for this scenario.

Code: https://github.com/damienbod/ExcelFileExportWithOAuth2ImplicitFlow

OAuth2 Implicit Flow
The application uses the OAuth2 Implicit flow. This flow is defined here:


Resource Server

The resource server is a simple MVC application which hosts a Web API 2 service. The api has one single method for exporting excel data. This export uses the WebApiContrib.Formatting.Xlsx library from Jordan Gray. The api method forces that excel is always returned no matter what is set in the Accept Header. This is not usually good practice as the client should decide in which format…

View original 1,529 more words

Posted in Uncategorized | 2 Comments

Covert Redirect – really?

In the era where security vulnerabilities have logos, stickers and mainstream media coverage – it seems to be really easy to attract attention with simple input validation flaws. Quoting:

“Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners.”

Oh yes – and amongst a myriad of other scenarios this also applies to URLs of redirect based authentication/token protocols like OAuth2, OpenID Connect, WS-Federation or SAML2p. And guys like Egor Homakov have already shown a number of times that you are bound to be doomed if you give external parties too much control over your redirect URLs.

The good thing is, that every serious implementer of the above protocols also reads the specs and accompanying threat model – e.g. quoting the OpenID Connect spec (section :

REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison)”

Or my blog post from over a year ago:

“If you don’t properly validate the redirect URI you might be sending the token or code to an unintended location. We decided to a) always require SSL if it is a URL and b) do an exact match against the registered redirect URI in our database. No sub URLs, no query strings. Nothing.”

So this type of attack is really a thing of the past – right?

Posted in .NET Security, AuthorizationServer, IdentityServer, OAuth, OpenID Connect, Uncategorized, WebAPI | 3 Comments

IdentityServer v3 and Azure WebSites (and other Deployment Simplifications)

(applies to preview 1)

A common request for IdentityServer was being able to run on Azure WebSites (or other constrained deployment environments where you don’t have machine level access). This was never easy because our default implementations in v2 had a dependency on the Windows certificate store which is typically not available in those situations.

Note: A security token service is typically not a good candidate for shared / high density hosting – especially on a public cloud. There are certainly exceptions to that rule, e.g. for testing scenarios as well as private clouds – also – e.g. Azure WebSites do support modes where the machine is not shared between tenants.

1 Loading the signing key
IdSrv3 supports two modes for signing the identity token – either asymmetric using the default x.509 signing certificate or symmetric using the secret of the requesting client. In the latter case no certificates are needed at all for identity tokens.
Similar for access tokens – either you use the X.509 certificate and self contained tokens (JWTs) or you use reference tokens.

So IOW – if you want to get around X.509 certificates – you can. But quite frankly, for most situations asymmetric signatures are really what you want – so we made it much easier to deal with certificates in v3.

The heart of IdSrv3 is the ICoreSettings interface – on there you can find the GetSigningCertificate method from where you return an X509Certificate2. How you load that certificate is now totally up to you – from the certificate store, from a file, blob storage – or like in our test setup – from an embedded resource (we will actually add some helpers to simplify that in a later release). This gives you a fair bit of flexibility.

2 Public vs internal host name
In many (shared) hosting scenarios, your local machine name and the machine / DNS name that external parties will use is different. That could be due to CNAME settings, reverse proxies, load balancers and SSL termination. We added support for that in IdSrv v2 – and it was a bit painful since it was an afterthought. In v3 you can now specify the public host name on ICoreSettings (see above) – see here for an example. If you don’t specify anything here, we assume the value of the host header and SSL.

3 Managing deployment configuration
The above settings are all in code, so you might wonder how you maintain different “configurations” for different deployment scenarios.

One approach would be surely to load the variables from web.config and use config transforms during publishing. This will get very complicated very quickly. The current approach we use is to maintain several Katana startup files, one for each deployment environment. A lesser known feature of Katana is, that you can specify the startup class in web.config, e.g.:


      <add key=owin:AppStartup value=LocalTest />


..and then map the value LocalTest to a startup class in code:

[assembly: OwinStartup("LocalTest", typeof(…))]

You can then use config transforms to use the right startup class for your target environment, e.g.:


      <add key=owin:AppStartup





I hope the above changes make hosting and deployment easier in IdSrv3 – I you have any feedback please come to the github issue tracker and join the conversation!

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