Practical ASP.NET Core SignalR: Authorization

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Leave this field empty if you're human:

In this section, I’m going to cover how to configure your clients to send access tokens to an ASP.NET Core SignalR Hub for Authorization.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

If you haven’t already, check out the prior sections of this course.

1. Course Overview
2. ASP.NET Core SignalR Overview
3. Basics
4. Server Hubs
5. HubContext

Authorization

For the most part, everything works as expected when using Authrozation behind ASP.NET Core. Meaning, you can use the [Authorize] attribute on Server Hubs just like you would on Controllers.

However, if you are using WebSockets as the transport and are using access tokens, then there is a bit of configuration required.

Client Configuration

In the signalR.HubconnectionBuilder().withUrl() allows us to specify an options object that has a property called accessTokenFactory which is a function needs to return the access token.

Where “MyTokenGoesHere” is a string, you would likely be using a means to return the access token you send with all of your other HTTP calls from the rest of your frontend application.

Query String

When the browser/client connects to the hub, it will add a query string parameter called “access_token“. The value will be what is returned from the accessTokenFactory.

ws://domain/messages?id=XXX&access_token=MyTokenGoesHere

Authorization Header

The reason for the SignalR client library for using the Query String to send the access token is that web sockets do not support the Authorization header. You can read more about this over at this GitHub issue.

Setting Token

Now that the access token is being sent via the query string, we need to configure out authentication in the Startup.cs to look for it in the query string and set it on the HttpContext.Token so that our authorization can use it as if it were coming from the Authorization header.

To do this with JWT, we can specify Events option and implement the OnMessageReceived property which is an Action<HttpContext>

We will implement this to look for the access_token in the query string, and if it exists, set it to the Httpcontext.Token

Get The Course!

You’ve got several options:

1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
2. Access the full course now by enrolling for free on Teachable.
3. Follow along with the blog post series here on CodeOpinion.com
   1. Course Overview
   2. ASP.NET Core SignalR Overview
   3. Basics
   4. Server Hubs
   5. HubContext
   6. Authorization
   7. Scaling with Redis
   8. Scaling with Azure SignalR Service

Follow @CodeOpinion

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.