Earlier the year I wrote a blog post which described how to access the JWT Bearer token when using ASP.NET Core 2.0. Though that was specifically for when using the JWT middleware, you could also use that technique when using the OIDC middleware. In ASP.NET Core 1.1 So for example, in ASP.NET Core 1.x, if you wanted to access the tokens (id_token, access_token and refresh_token) from your application, you could set the SaveTokens property when registering the OIDC middleware:
When using the ASP.NET Core OpenID Connect middleware, after a user has signed in you can access the name of the user by using the User.Identity.Name property. What this does under the cover is to look for the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name claim type and then return that value. In the case of Auth0, we actually return a user’s name in the name claim of an id_token and this does not get automatically mapped to the http://schemas.
When using JSON Web Tokens (JWTs) as Bearer tokens in your ASP.NET Core Web API, it may sometimes be required to access the actual token which was passed to the API somewhere else in your API. For Remote Map for example I have the requirement to access the user’s full profile under certain conditions. I want to store some of the user’s personal information in the local database, and in order to obtain their information I have to call the /userinfo endpoint of the Auth0 Authentication API.
It seems I have not had much success with announcing my intentions to start a new project and blog about it. Before long something more interesting comes along and I am off in another direction and working on a new pet project. Case in point: GeoToast Well, seems I don’t learn as I am trying this again. This time however I have better motivation to get this done (I think).
In my previous blog post I gave an overview of how you can create a serverless application using .NET Core and AWS Lambda. In this blog post I will show a similar - yet quite different - programming model. Instead of using just plain .NET Core, I’ll be using ASP.NET Core with AWS Lambda. A quick reminder from my introductory blog post in this series may be in order.
Previously I gave an overview of the programming models when using NET Core with AWS Lambda, and I also showed how to create an image compressor in Lambda and C#. This time around we’ll put together a simple Web API with a couple of endpoints which can be called from any client application. The API I’ll create will utilize NodaTime library created by Jon Skeet to return a list of time zones based on the Time Zone database.
This blog post will provide you with a brief introduction to using C# and .NET Core with AWS Lambda and also look at the different programming models available when using .NET Core with Lambda. The reason why I started looking into this was because I wanted a dead simple hosting solution for GeoToast. And yeah, it has been a while since I have written about GeoToast. I spent a month in Japan, and sightseeing was higher on my list of priorities than coding…
Things I learned Rename Refactor in VS Code In last week’s update I alluded to the fact that I miss many of the refactorings which is offered by Visual Studio and Resharper. One good find this week is that VS Code at least has Rename Symbol functionality. As explained by the VS Code Documentation: Some languages support rename symbol across files. Simply press F2 and then type the new desired name and press Enter.
I have been working on GeoToast and one of the things I needed to handle was returning a response when model validation fails when calling any of my API endpoints. I am also using Fluent Validation for my model validation which I talked about in my previous post, but that has no bearing on this blog post. This blog post deals with ModelState and FluentValidation ultimately updates the ModelState so whether you are using normal data annotations attribute validation, or Fluent Validation, this will work the same.