NDC Oslo 2014 Slides, Samples and Videos

As always – NDC was a great conference! Here’s the list of resources relevant to my talks:

IdentityServer v3 preview: github

Web API Access Control & Authorization: slides / video

OpenID Connect: slides / video

 

Posted in ASP.NET, Conferences & Training, IdentityServer, OAuth, OpenID Connect, WebAPI | 2 Comments

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”

kthxbye

Posted in Uncategorized | 1 Comment

100k Downloads of Thinktecture IdentityModel

Amazing!

nuget100k

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

image

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:

http://tools.ietf.org/id/draft-ietf-oauth-v2-31.html#rfc.section.4.2

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 3.1.2.1) :

redirect_uri
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