Release Candidate for Katana 3 and the ASP.NET Security Components

Release Candidate for Katana 3 and the ASP.NET Security Components

Rate This
  • Comments 10

One step closer to GA! The release candidate NuGet packages for Katana 3 are now available on the gallery, published with version 3.0.0-rc2.

Most of this release consists of bug fixes and stabilization updates, with the exception of the ASP.NET security components.

What’s New with the ASP.NET Security Components in the Release Candidate

You can install or update the release candidate bits through the Package Manager Console. If you were using WS-Federation, get the corresponding package with the following command:

Install-Package Microsoft.Owin.Security.WsFederation -Pre

If you were using OpenId Connect, use the following:

Install-Package Microsoft.Owin.Security.OpenIdConnect -Pre

Finally, you’ll want the new cookie middleware and, if you develop against IIS, you’ll want SystemWeb too:

Install-Package Microsoft.Owin.Security.Cookies -Pre

Install-Package Microsoft.Owin.Host.SystemWeb -Pre

Once again, this release features both feedback-driven updates and brand new features.

We’ll dig deeper in every new feature in the coming weeks, but to give you a sense of the scope of the changes:

  • In earlier previews we exposed protocol artifacts strictly following the protocol specification and their wire values, which resulted in a lot of property names containing ‘_‘.
    You were very vocal in requesting that we give priority to the .NET naming conventions, hence all underscores are now gone. That means that if you wrote code against preview bits you’ll almost certainly have to update it, but the good news is that it’s a very easy change.
  • We added some features that are not directly visible in the OM, such as the ability for apps to update their validation keys in adaptive fashion – so that apps can self-heal in case of key rollover without requiring a restart. That affected the programming model in indirect ways: for example, this feature called for a refactoring of how protocol options are stored and handled.
  • We added some advanced capabilities: the already described reference mode session, which allows you to write web apps that can be consumed by mobile devices with hard cookies size limits; we added a mechanism for automatically detecting token replay attacks; we made it easier for you to control the duration of sessions; and so on.
  • Of course, we fixed lots of bugs. A big thank you for reporting those!!! Please keep ‘em coming!

The main OM changes are demonstrated in the samples in filter the repos by ‘OpenId’ or ‘WsFed’.


At this point we don’t plan to introduce further changes to the development surface of the components: we’ll be doing stabilization work, and as soon as we’ll hit the right quality bar we’ll make the bits generally available. Please help us to weed out the last bugs as we work through the final stretch! As usual, there are many ways for you to engage:

Thanks and enjoy!

Leave a Comment
  • Please add 1 and 5 and type the answer here:
  • Post
  • Oh, The next version of ASP.NET rules!!!

  • A good blog for the ASP.NET Security Components.Its vey helpful.

  • How come there is no support for the server part of OpenId Connect? You provide support for server bits of OAuth, but only client part of OpenId Connect?

  • Hi Khaled,

    with "server part" do you mean the authorization server? ASP.NET does provide an Authorization Server implementation, OpenId Connect mostly layers some specific parameters on top of it. However please note that building an issuer is a very difficult task: the protocol support functionality is the easy part, the challenge is in making the server secure, available, performing, scalable, manageable and so on.

    More often than not, relying on an existing provider yields the best results - which is why the emphasis in this release is about enabling that.



  • @Khaled: I started working with @manfredsteyer on an OWIN OpenID connect server, based on the OAuthAuthorizationServerMiddleware designed by the Katana team. It offers the same low-level experience and exposes tons of hooks to control the whole authentication/authorization flow.

    Please note this is still an experimental project, even if it is based on the rock-solid OAuthAuthorizationServerMiddleware. If you see a bug or wanna discuss about the project, feel free to visit the GitHub repository.

    If you're looking for a turnkey solution, you may also consider using IdentityServer.v3, made with love by Thinktecture:

  • I've just been evaluating using Katana 3 middleware with IdentityServer v3 from Thinktecture.

    Current state of play is you could use the two together for Implicit Flow, but not out of the box for Code Flow or Hybrid Flow.  

    For the full detail, please see:

  • How do I extract the claims in an access token in the client if the Token was generated by a WEBAPI? I am able to get the Token back, but unable to get any claim value I set in the web api in the mvc calling app. I can use the token as is but cannot access the claims I set on the Server in the client. Can you help? I am using Owin/Katana with  no frills, no external logins etc

  • Hi Shirish,

    I am not sure I understand your scenario. Can you expand on what do you mean with "generating a token in a WEBAPI"? Normally the token is issued by one authority like Azure AD or ADFS. I am also not following the client-server flow of claims you described. Feel free to keep the thread here, or contact me at and we can go on via mail. Thanks!


  • Vittorio - Thank you for looking at this. Here is my Use case in more detail.

    1. WEBAPI project in a solution using Owin/Katana to generate bearer tokens. I am not Federated in any way.

    public partial class Startup{

           static Startup(){

               PublicClientId = "self";OAuthOptions = new OAuthAuthorizationServerOptions{TokenEndpointPath = new PathString("/token"),Provider =  new ApplicationOAuthProvider()};}

           public static OAuthAuthorizationServerOptions OAuthOptions { get; private set; }

           public static SomeIdentityUser UserManagerFactory { get; set; }

           public static string PublicClientId { get; private set; }public void Configuration(IAppBuilder app) {var config = new HttpConfiguration();app.UseWebApi(config);




    MY grantresource owner credentials in the WEB API is as follows

    public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context){

                using (var userManager = _userManagerFactory){

                   SomeIdentityUser user = await userManager.FindAsync(context.UserName, context.Password);

                   ClaimsIdentity oAuthIdentity = await userManager.CreateIdentityAsync(user,


                   var properties = CreateProperties(user);

    // i am trying every way to set claims for MVC UI app. so forgive any errors

                   oAuthIdentity.BootstrapContext = oAuthIdentity;

    var ticket = new AuthenticationTicket(oAuthIdentity, properties);

                   context.OwinContext.Request.User = new ClaimsPrincipal(oAuthIdentity);

                   context.Request.User = new ClaimsPrincipal(oAuthIdentity);

                   context.OwinContext.Response.Context.Authentication.User = new ClaimsPrincipal(oAuthIdentity);

                   context.Validated(ticket); }}

    2. Create a second MVC calling app in the same solution and call the token endpoint to login

    public async Task<ActionResult> Login(LoginViewModel model, string returnUrl){var httpClient = new WebClient(); ;httpClient.Headers.Add("Accept", "application/json");httpClient.Headers.Add("Content-Type", "application/x-www-form-urlencoded");var strContent = String.Format("grant_type=password&username={0}&password={1}", model.Email, model.Password);

    byte[] byteArray = Encoding.ASCII.GetBytes(strContent);

    byte[] respContext = httpClient.UploadData("http://localhost:55337/token", "POST", byteArray);

    if (respContext != null){

    var response = HttpContext.GetOwinContext().Response.Context;                

    if (response.Response.StatusCode == 200){

    var stringContent = Encoding.ASCII.GetString(respContext);JObject jObject = JObject.Parse(stringContent);

    var token = jObject.SelectToken("access_token");

    // how do I get claims that I set in API here?? The Principal object is always generic principal

    // and i do not see the claims identity i set in the API here}}}

  • Shirish, by default the access tokens issued by the authorization server middleware are opaque to the client. You can optionally provide a Web API endpoint that the client can call to request the claims for the token (ex. a MeController that serializes the claims to JSON). Alternatively you can switch to using an open token format like JWT, but this means you are now making the token format part of your public surface area that clients can depend on.

Page 1 of 1 (10 items)