State of Web API

I've spent the past few days reading about ASP.NET/Web API/Katana/ASP.NETCore and so on. The terrain seems to be shifting every couple years, and MS is reinforcing that feeling. At this point, after all the reading I have done, I'm not sure what is current and what is not, except that I'm pretty sure that I'm not.

I'm using Web API in 4.7.2. From what I have seen and tried, that can use some ASP.NETCore, but not everything. There are plenty of packages that won't install on framework, and require Core 2.x or 3.x.

Meanwhile Katana seems current, while ASP.NET appears somewhat deprecated by MS, though still viable. Does that sound right?

Ultimately, I'm looking to consume JWT tokens in a FW 4.7.2 application. There appears to be an abundance of means, none of which appear all that well documented. It looks like an OWIN approach using Microsoft.Owin.Security.Jwt would be both reasonably current, and likely to be sustainable for a few years. It also looks like VB.NET might be in Core 3.x by this fall/winter, which....actually complicates the situation, as one alternative was always to move over to C# for this and just build it in Core. I'd prefer to stick with FW for these reasons:

1) The API is already written, tested, and deployed, so a re-write holds little appeal.
2) I think it might be a bit less of a black box, though not by much.

Basically, I've found a whole lot of dubious articles on consuming/validating JWT tokens, along with a few that are pretty good. I'd probably go with one that has reasonably good documentation, which is why I am currently favoring Katana. However, I thought I'd ask for suggestions here. The amount of weak documentation is impressive. Some folks could use an editor...including me, so I'm sympathetic to the situation, but still....

So, any suggestions?

The terrain is shifting but actually it shifting to more stable ground.

.Net Core is a complete re-write of .Net from the ground up which you probably already know, the language is the same but the structure underneath has changed quite a bit mainly for the better. You experience this by the libraries and tools you have at your disposal as part of the framework to do stuff, they feel nicer to use as generally they have been designed with modern web development in mind.

Quote:

---

I'm using Web API in 4.7.2. From what I have seen and tried, that can use some ASP.NETCore, but not everything. There are plenty of packages that won't install on framework, and require Core 2.x or 3.x.

---

You should think of .Net core as being separate from the old framework, they really dont mix that well. You can create a solution with .net Core projects and .Net 4.7.2 projects in it and compile and create programs this way but generally you wouldn't want to as you lose some of the advantage of .Net Core.

Quote:

---

Meanwhile Katana seems current, while ASP.NET appears somewhat deprecated by MS, though still viable. Does that sound right?

---

Not really, you can use ASP.NET in .Net Core too in fact my current project i am working on is and ASP.NET Core 3.1 Web MVC project, with a .Net Core 3.1 Web Service (the Startup is slightly different from Web Api but other then that is incredibly similar).

Asp.Net in .Net Core is very similar to what it was in the old Framework, but they have changed some of the framework libraries and some of the initial startup routing.

Katana is not seen as go forward most people are using Identity server 4 - if you google - identityserver4 jwt authentication you will get plenty of good resources for this.

.Net Core soon to just be .Net Framework 5, is still .Net its not some huge leap or at least it doesn't have to be, what it does do is offer you a set of tools as part of the framework that are new and generally better for building modern web apps and web services, which of these tools you need or choose to use is up to you.

One thing you should bear in mind you to use .Net Core it is a separate download for the framework, and also it only works with VS 2019 (for PC or Mac)

Quote:

---

Katana is not seen as go forward most people are using Identity server 4

---

Greeeeaaaat! That pretty much sums up my frustration through all of this. Katana was relevant only a few years ago. Pages about that, even those from MS, aren't labeled in any way to suggest that they are out of favor. For one thing, the bloody web needs timestamps. Some people date their pages, others do not. Google can't tell what is current and what is dated, so you get the chaff with the wheat. I guess you always get that on the web, it's just worse in this area because it is changing so fast. Perhaps the changes are to something more stable, but a modest examination of the history suggests this is not going to be the case. Every new approach talks about it as being the greatest thing replacing all that came before, bringing us into a glorious new future, and allowing us all to divide by zero. Then a couple years go by and the cycle starts over with the next latest new thing. The web doesn't forget, either, so you can find the different layers, all mixed together like an archaeological nightmare.

I have no optimism that the latest will be either the greatest, or the final. It will all be deprecated within a couple years.

I'll certainly take a look at Identity Server 4, and even go that route. I just need to be able to use a JWK to validate a JWT (I might have a TLA wrong, one of those looks wrong to me) by a means that can survive for a few months before it all changes once again.

Quote:

---

Greeeeaaaat! That pretty much sums up my frustration through all of this. Katana was relevant only a few years ago. Pages about that, even those from MS, aren't labeled in any way to suggest that they are out of favor.

---

Yeah i can see why it can be frustrating, if your doing this stuff everyday then after a while you get used to churn rate of new stuff but if your not i imagine it can look a like like a constantly moving target.

Even with that said we have changed approach 3 times in 3 projects at my work as we move to the newer platform stuff, which is both rewarding and frustrating at times.

Identity Server is pretty solid though, its seen as an industry standard and MS have seem to be backing it pretty well, i dont see it going anywhere soon.

Yeah, if you are constantly working with something, you don't just know it better, you understand the point behind any change, and probably appreciate improvements. In my case, this is almost an afterthought tacked onto a different project. I address it only when something fails, which has been infrequent over the last 12 years. I have the opportunity to forget darn near everything about it between needing to do anything with it.

Well, you pointed me towards IdentityServer4, and I certainly recognized that. The person who set up our system clearly used that...and is leaving, so it's good to know something about the background.

What I'm seeing is that there are things that are clearly ASP.NET Core. For example, lots of examples make use of a method called ConfigureServices in the Startup class. From the testing I have done, that appears to be Core specific, though I have not found any explicit statement to that effect. What I found was that I can certainly add such a method, but it doesn't get called at all in a framework based Web API project.

The vast majority of what I am finding is pushing me towards rewriting in C# for Core, but it doesn't seem like I should need to, and I feel that I'm close. I'm just wandering through a maze of different technologies, some current, others dated.

At this point, I have the JWT token, and it looks right. I also have the JWK that was used to sign it, but I haven't figured out how to validate the JWT with the JWK (or at least what I tried isn't working), and I'm not sure if that's because I'm misunderstanding how to use the JWK, or if the method I tried is just too horribly archaic, or if I implemented it wrong.

I would say that the biggest issue I'm having is that it's a black box, which is how it should be. I'm getting Authorization is Denied, which doesn't surprise me, but there are many ways I could have gotten it wrong through omission or commission, and they would all result in the same, opaque, result.

Since ConfigureServices doesn't get called, there's nothing going on in there. Thus, everything is in Congifuration, which follows the OWIN stack, which is semi-retired. That has the one method, which is Configuration and takes an IAppBuilder. I confirmed that this is getting called, and it compiles.

Next, following an example I found, which may or may not be useful, I set up a JWTBearerAutenticationOptions object:

Code:

---

Dim jwtBAO = New JwtBearerAuthenticationOptions()
        jwtBAO.AuthenticationMode = AuthenticationMode.Active
        jwtBAO.TokenValidationParameters = New TokenValidationParameters()
        Dim TokenValidationParameters = New TokenValidationParameters With {
            .ValidateIssuer = True,
            .ValidateAudience = True,
            .ValidateIssuerSigningKey = True,

---

I then assigned the authorization endpoint to the ValidIssuer property of the TokenValidationParameters (which is the iss from the JWT), and the aud from the JWT to the ValidAudience. I found something that suggested that last step was wrong, though.

The final thing I set was to assign the IssueerSigningKey property a new SymmetricSecurityKey based on well, something.

What I found in the JWK was an x5c that went with the x5t and kid from the JWT. That x5c looked like Base64, but I assume it was Base64url. I needed a byte array, so i turned that x5c into a byte array with the Base64UrlEncoder found in IdentityModel.Tokens. That has several potential sources of failure:

1) I might have used the wrong encoder.
2) I might have decoded the wrong thing.
3) The whole approach might have been wrong.

Finally, I called

app.UseJwtBearerAuthentication(jwtBAO)

And now any call to an endpoint marked with the <Authorize> attribute fails. So, it didn't work, but it's mighty hard to debug, too.

I guess I'm looking for a framework based means to validate a JWT based on a JWK.

Quote:

---

What I'm seeing is that there are things that are clearly ASP.NET Core. For example, lots of examples make use of a method called ConfigureServices in the Startup class. From the testing I have done, that appears to be Core specific

---

Yep Configure Services is Core specific, its how they have reworked the Startup. It accepts IServiceCollection as a constructor and allows you to configure and add to it.

I think that the non .net core class you need is - JwtSecurityTokenHandler

https://docs.microsoft.com/en-us/pre...81(v%3Dvs.114)

That got me much closer. Unfortunately, I then got called away to other things. Hope to get back to it today.