Shulou(Shulou.com)06/02 Report--

How to use Jwt authentication to protect Asp.Net Core Web Api, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

There are many resources on the network that can teach you how to protect ASP.NET Core Web applications. I have written some, such as ASP.NET Core Identity From Scratch, External Login Providers in ASP.NET Core and Facebook Authentiation with ASP.NET Core.

However, there doesn't seem to be much useful information on the Internet to protect Asp.Net WebApi. Here I'll show you how to use Json Web Tokens (JWT) to protect Web Api in ASP.NET Core. I have a demo project in github, and you can follow it.

Use token instead of cookie

In a Web application, if you are not going to use an API that supplies external calls (such as a mobile application), it usually uses a cookie to represent a logged-in user.

The general process is as follows: the user clicks to log in, goes to the login page, and after entering valid credentials, the response sent by the server to the user's browser contains a Set-Cookie header with encrypted information.

Cookie will be set to domain such as blinkingcaret.com, and every time the browser sends a request to this domain, the cookie set on this domain will also be brought.

On the server, the cookie is decrypted and then the decrypted content is used to create the user's Identity.

If the client is a browser, this approach will be very suitable. But when our client is a mobile application, that's a different story.

JWT

What can we use instead of cookie? Yes, it is token. Token also represents users, but when we use it, we no longer rely on the browser's built-in mechanism and use it to deal with cookie.

We must explicitly ask the server for a token, store it somewhere ourselves, and then manually take it with us as each request is sent. There are some ways to make this as simple and fast as possible, and I'll discuss some of them later.

The token format I will discuss here is JWT.

JWT stands for Json Web Token. JWTtoken has the following format base64-encoded-header.base64-encoded-payload.signature.

An example of heder is

{"alg": "HS265", "typ": "JWT"}

Payload contains a series of claims, such as:

{"name": "Rui", "admin": true}

Finally, the signature is created by using "base64 (header) .Base64 (payload)" and encrypted using the algorithm specified in the header. For example, HMAC-SHA256. The signing part uses a key stored on the server, which is not sent to the client.

Here is an example of a real JWT:

EyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoicnVpIiwic3ViIjoidGVzdCIsIm5iZiI6MTUwMzYxNDU4NSwiZXhwIjoxNTA2MDMzNzg1LCJpc3MiOiJibGlua2luZ2NhcmV0IHN0cyIsImF1ZCI6ImJsaW5raW5nY2FyZXQgYXBwIn0.F7PFoYcQXez3zV98BFKLpyON6d_1p-6IAeihZRSv0VM

You must note that the information contained in JWT is not encrypted. To get a valid payload, you only need base64 decoding. You can even do this from your developer tools console (for example, in Chrome). Use the atob method and pass payload as a parameter. You will get the decrypted JSON. Signature can only guarantee that if someone tampers with payload, then signature will fail. If someone wants to successfully replace the payload and generate a valid token, they need to know the key used in the signature, but that key will never be sent to the client.

So, when you want to put something in the payload, you must know the above.

Translator's note: just don't put sensitive information in payload, such as passwords.

Using JWT in ASP.NET Core

To use JWT in ASP.NET Core, we need to know how to create JWTtoken manually, how to validate them, and how to create endpoints so that client applications can get them.

How to create a JWTtoken

First you need to install the nuget package System.IdentityModel.Tokens.Jwt:

$dotnet add package System.IdentityModel.Tokens.Jwt

Then create a key. We will use symmetric key with the following code:

Var secretKey = new SymmetricSecurityKey (Endoding.UTF8.GetBytes ("a secret that needs to be at least 16 characters long"))

Translator's note: a secret that needs to be at least 16 characters long= > A password that requires at least 16 characters is also used when verifying signatures.

Our token will contain a set of claims. So let's create them:

Var claims = new Claim [] {

New Claim (ClaimTypes.Name, "John")

New Claims (JwtRegisteredClaimNames.Email, "john.doe@blinkingcaret.com")}

I have used two types of claim:

ClaimTypes (System.Security.Claims)

JwtRegisteredClaimNames (System.IdentityModel.Tokens.Jwt)

It is important to emphasize that JwtRegisteredClaimNames is included in the claims enumerated in JWT RFC. If you plan to use token generated by different programming languages or frameworks, you should use this as much as possible for compatibility. However, there are some declaration types that can enable certain features in ASP.NET. For example, ClaimTypes.Name is the default declaration type for user name (User.Identity.Name). Another example is ClaimTypes.Role. If you use the Roles attribute in the Authorize attribute (for example, [Authorize (Roles = "Administrator")]), this declaration will be checked to confirm permissions.

After creating the claims list that we want to encode in token, we can create the token itself as follows:

Var token = new JwtSecurityToken (

Issuer: "your app"

Audience: "the client of your app"

Claims: claims

NotBefore: DateTime.Now

Expires: DateTime.Now.AddDays (28)

SigningCredentials: new SigningCredentials (key, SecurityAlgorithms.HmacSha256))

Here are some concepts that I didn't mention before, namely issue,audience and expiration dates.

Translator's note: publisher, audience / audience, expiration time

The publisher represents the entity that generated the token, which in this case is the ASP.NET Core Web application. Audience represents the entity that will use these token, such as client. This issue and audience are important if you rely on third parties to create token (not what you need now). When verifying token, you can verify issue and audience.

NotBefore and expire define the valid time interval for token, after notBefore and before expire.

Finally, specify which security key and what algorithm to use to create the signature in signedCredentials. In this example, we use HMAC-SHA256.

If you don't care about issue and audience (optional in the JWT specification), you can use a simpler constructor overload that accepts JwtSecurityToken for JwtSecurityHeader and JwtSecurityPayload. However, you must manually add expires and notBefore declarations to valid content, such as:

Var claims = new Claim [] {new Claim (ClaimTypes.Name, "John"), new Claims (JwtRegisteredClaimNames.Email, "john.doe@blinkingcaret.com"), new Claim (JwtRegisteredClaimNames.Exp, $"{new DateTimeOffset (DateTime.Now.AddDays (1)). ToUnixTimeSeconds ()}"), new Claim (JwtRegisteredClaimNames.Nbf, $"{new DateTimeOffset (DateTime.Now). ToUnixTimeSeconds ()}") var token = new JwtSecurityToken (new JwtHeader (new SigningCredentials (key, SecurityAlgorithms.HmacSha256)) New JwtPayload (claims))

Note that the value declared by Exp (expires) and Nbf (notBefore) is a string of Unix times. The easiest way to convert DateTime to this format is to use DateTimeOffset.

After creating an instance of JwtSecurityToken, the actual way to generate token is to call the WriteToken method of the JwtSecurityTokenHandler instance and pass JwtSecurityToken as a parameter:

String jwtToken = new JwtSecurityTokenHandler () .WriteToken (token); create an endpoint that gets the token

Now that we know how to create our JWT token, we also need a way for the client to get them. The easiest way is to create a web api controller action that expects to publish the request to accept a Post request, such as the following code:

Public class TokenController: Controller {[Route ("/ token")] [HttpPost] public IActionResult Create (string username, string password) {

If (IsValidUserAndPasswordCombination (username, password))

Return new ObjectResult (GenerateToken (username))

Return BadRequest ();} / /.

In IsValidUserAndPasswordCombination, you can verify the user's credentials such as using ASP.NET Identity (if you need resources to learn about ASP.NET Identity, you can read this blog ASP.NET Identity Core From Scratch).

GenerateToken we just described in the previous section.

Authenticate users and log them in

Now that we have a way to distribute token, we need a way to verify them. We will use ASP.NET Core's authentication middleware and configure it to accept JWT token.

Add the Microsoft.AspNetCore.Authentication.JwtBearer NuGet package to your project.

$dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

Next, open Startup.cs and update the ConfigureServices method:

Public void ConfigureServices (IServiceCollection services) {/ /... Services.AddAuthentication (options = > {options.DefaultAuthenticateScheme = "JwtBearer"; options.DefaultChallengeScheme = "JwtBearer" ) .AddJwtBearer ("JwtBearer", jwtBearerOptions = > {jwtBearerOptions.TokenValidationParameters = new TokenValidationParameters {ValidateIssuerSigningKey = true, IssuerSigningKey = new SymmetricSecurityKey (Encoding.UTF8.GetBytes ("your secret goes here")), ValidateIssuer = true, ValidIssuer = "The name of the issuer" ValidateAudience = true, ValidAudience = "The name of the audience", ValidateLifetime = true, / / validate the expiration and not before values in the token ClockSkew = TimeSpan.FromMinutes (5) / / 5 minute tolerance for the expiration date} });}

If you are not familiar with ASP.NET Core authentication middleware, it is recommended that you read External Login Providers in ASP.NET Core.

Even if it's about how to log in to an external login provider such as Google,Facebook, this blog also contains detailed instructions on how authentication middleware works.

Also note that this is the new ASP.NET Core 2.0 syntax, where authentication is fully configured through the ConfigureServices method, but the concept is the same.

Translator's note: External Login Providers in ASP.NET Core this blog was written using Asp.Net Core 1.x.

More important in this example is the TokenValidationParameters class. This is the class you must instantiate and it will be used to configure how to validate token.

In Startup.cs, you need to update the Configure method and add authentication middleware:

Public void Configure (IApplicationBuilder app, IHostingEnvironment env) {/ /. App.UseAuthentication (); / / needs to be up in the pipeline, before MVC / /... App.UseMvc (ConfigureRoutes); / /.. Client client

Web api clients can be desktop applications, mobile devices, or even browsers. The example I'll describe is logging in to a Web application, saving the token, and then using it to perform authentication of the request. You can find an example that works here.

First, in order to be able to log in, you need to send the user name and password to the POST request to "/ token" (or the Web Api breakpoint you set to get the token). You can easily use jQuery to do this:

$.post ("/ token", $.param ({username: "the username", password: "the password"})) .done (function (token) {/ / save the token in local storage localStorage.setItem ("token", token); / /...}) .fail (handleError)

If all goes well, you can get the JWT token, and then you can save it somewhere, usually in a Web application, where we save it to local storage. On mobile devices, it depends on the platform you use, but they all have features that allow you to save token (such as Android's SharedPreferences).

For the authentication middleware in the previous section, to accept the JWT token and convert it to a User that can be accessed in the controller operation, the request must have an Authorization header. The value of header should be "Bearer", followed by JWT token, for example:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1l...

Although you can "manually" add authorization headers to each request, there is usually a way to execute them automatically. For example, there is a time in jQuery that allows you to do something before sending a request, such as checking here for the existence of token, and if so, adding it to the Authentication header.

$.ajaxSetup ({beforeSend: function (xhr) {

If (localStorage.getItem ("token")! = = null) {xhr.setRequestHeader ('Authorization',' Bearer'+ localStorage.getItem ("token"));})

If you use other frameworks, there are similar mechanisms, such as Angular with HttpInterceptors.

Finally, you only need to delete the token from the local store to log out:

LocalStorage.removeItem ("token")

One thing to note is that if the client performs an operation that requires the user to authenticate and there is no (valid) authorization header in the request, the server will return a response with a 401 status code. The response will also have a WWW-Authenticate:Bearer header. If you receive such a response, you can notify the user that you need to verify your identity.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.