I’ve spent a lot of time over the last 16 months or so working with ASP.NET Web API and Microsoft.Owin’s UseOAuthAuthorizationServer middleware extending it with custom OAuthAuthorizationServerOptions, ISecureDataFormat<T>, OAuthAuthorizationServerProvider and IAuthenticationTokenProvider implementations.

This included the use of the System.IdentityModel.Tokens InMemorySymmetricSecurityKey used in the SigningCredentials constructor to be used in signing the JWT token. And when I went to port all of this to ASP.NET Core, I learned to my surprise that there is no equivalent to UseOAuthAuthorizationServer middleware and there is no InMemorySymmetricSecurityKey. Instead, you’re on your own for creating your own authentication/authorization middleware and signing a JWT is done using a SymmetricSecurityKey (a class that used to be abstract but now is not).

Here’s my first attempt:

salt = salt ?? "0a987sdf7asdg896asdf6as9df7a7sdf8asd";
var keyBytes = Encoding.UTF8.GetBytes(
    Convert.ToBase64String(Encoding.UTF8.GetBytes(SecKey + salt)));
_symmetricSecurityKey = new SymmetricSecurityKey(keyBytes);
_tokenValidationParameters = new TokenValidationParameters
{
    CryptoProviderFactory = _symmetricSecurityKey.CryptoProviderFactory,
    ValidateIssuerSigningKey = false, //true,
    IssuerSigningKey = _symmetricSecurityKey,
    ValidateIssuer = true,
    ValidIssuer = "issuername",
    ValidateAudience = true,
    ValidAudience = "all",
    ValidateLifetime = true,
    ClockSkew = TimeSpan.Zero
};
_signingCredentials = new SigningCredentials(_symmetricSecurityKey, "HS256");

A very good blog post on this topic can be found on Stormpath’s blog. I highly recommend you read that blog post. There are any number of ways to code up your “token” endpoint. I like how easy it is to write a custom authentication and authorization token endpoint using ASP.NET Core. More fun with .NET Core to follow.

I really enjoy reading Oren Eini’s blog at https://ayende.com/blog/ and his last two blog posts about a race condition in a TCP interaction he was able to resolve was classic Oren.

Read the first post here. The lesson learned in the second post is don’t switch streams. A very interesting lesson indeed.

If you are not already a fan and reader, I recommend you become one.

I’m a big believer in establishing standards for your REST APIs. I like this one from Microsoft but there are others. What I like about this particular guideline is the structural organization and its brevity. The introductory paragraph provides the reasoning and justification behind REST even when there are language specific SDKs made available.

Developers access most Microsoft Cloud Platform resources via RESTful HTTP interfaces. Although each service typically provides language-specific frameworks to wrap their APIs, all of their operations eventually boil down to REST operations over HTTP. Microsoft must support a wide range of clients and services and cannot rely on rich frameworks being available for every development environment. Thus a goal of these guidelines is to ensure Microsoft REST APIs can be easily and consistently consumed by any client with basic HTTP support.

One thing that would be nice to have is a standard for filtering, paging, etc., on the URL as query parameters. These get defined differently by every REST service architect out there. Or so it seems. A good jumping off point for some research and thought.

And I want to thank my friend Pablo for sending me the link to this.