Category Archives: OWIN

Home / Security / OWIN
13 Posts

It seems like only yesterday when I setup an OWIN OAuth server to provide single-signon capabilities for all of my apps. Since that time, though, OWIN has kind of fallen to the wayside in favor of newer security mechanisms in .NET Core. However, it is possible to make an OWIN application play nice with a .NET Core application to share cookie-based authentication.

More Link

Since the OAuth server I’ve detailed previously is using OWIN, I’ve been looking at what it will take to move it to .NET Core. The OWIN OAuth Server provides all of the Secure Token creation. This functionality is not provided with .NET Core’s native middleware.

My first thought is to integrate with IdentityServer4 or Openiddict which provide Secure Token generation and are .NET Core compatible. After some cursory information gathering, I’m putting a few research links here for later use.

https://blogs.msdn.microsoft.com/webdev/2016/10/27/bearer-token-authentication-in-asp-net-core/
https://blogs.msdn.microsoft.com/webdev/2017/01/23/asp-net-core-authentication-with-identityserver4/
https://github.com/openiddict/openiddict-core
https://www.scottbrady91.com/Identity-Server/Getting-Started-with-IdentityServer-4
http://stackoverflow.com/questions/35304038/identityserver4-register-userservice-and-get-users-from-database-in-asp-net-core

With a new project we have, I was tasked with working on security. Initially, I used OWIN and cookie authentication to implement a simple login and all was good. However, we wanted to remove the ability to login and have it driven by an external site redirecting a user with a token.

More Link

Previously, I blogged about writing your own handler to hook into the OWIN middleware pipeline. I’ve been using the handler I described in that post for quite some time now.

However, after a bit of QA, I noticed at least one strange behavior.

More Link

After creating a redistributal package for a custom OWIN AuthenticationHandler that handles logins to an internally hosted Oauth2/SSO provider, I found something a little annoying.

When OWIN detects a 401 response and the AuthenticationMode is “Active,” it doesn’t capture the URL hash from the request.

More Link

Being able to decrypt the OWIN AuthenticationTicket can be very useful. In the cases where the cookie/tickets are shared across applications, this is especially true.

Interestingly, if you’re using OWIN for both cookie-based authentication and access tokens, the Ticket is stored in both mediums.

With that in mind, the easiest method to decrypt a ticket to access claims, etc is to simply stand up a protected Resource server with a single Api endpoint to display the contents of the ticket. Going this route, the decryption is automatically handled by OWIN with very little code. The endpoint can be accessed by a user’s browser (decrypting the cookie) or by a server passing in a Bearer token.

More Link

With my previous endeavors using OWIN Middleware for an SSO Authentication system, I used DotNetOpenAuth as the client to make the OAuth Authorization Code grant flow. However, after a bit of research, I’ve learned that hooking into the OWIN Middleware can completely eliminate the need to use DotNetOpenAuth.

Additionally, eliminating DotNetOpenAuth and its dependencies makes creating a Nuget reusable package for the applications that I intended to use with the SSO/OAuth2 mechanism much simpler.

More Link

Adding custom claims in .NET Identity, through OWIN, or otherwise is pretty straight forward.

But, what if we want to step outside of, or augment, the OAuth flow?

More Link