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

IdentityServer4 migration to 3.x version of the attention problems, 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.

Basic issues of migration and upgrade

For the context [IdentityDbContext] in Identity, you need to download the following package:

[Microsoft.AspNetCore.Identity.EntityFrameworkCore]

For the configuration of the following client OIDC, you need to download the following package

[Microsoft.AspNetCore.Authentication.OpenIdConnect]

For client authentication and authorization configuration, you need to configure authorization middleware as follows (authentication and authorization are not in order)

We know that the migration name was previously included in dotnet CLI, but it has been modified to be done through a separate package, so we need to download the following prompt package, otherwise the following exception will be thrown

You may also encounter inconsistencies between the command line tool version and the current .NET Core version. Update it with the following command

There may not be any problems in the local environment, but when it comes to the production environment, the following mistakes may be thrown. Do we look confused?

In view of the above exception thrown, next through a long paragraph to explain the story about Cookie

Cookie Security Policy issues

When designing the cookie about 20 years ago and redesigning the cookie later, cross-site request forgery (CSRF) attacks and tracking users are not a big deal. According to the cookie specification, if cookie is set for a particular domain, every request made by the browser will be sent to that domain, whether or not we navigate directly to that domain, if the browser simply loads resources (that is, images) from that domain. Send a POST request to it or embed part of it into the iframe, but there is another case where we do not want the browser to automatically send the user session cookie to the server, as this will allow any website to execute a script that executes the request to the server in the context of that user. To avoid this situation, the SameSite cookie specification was drafted in 2016 It gives us better control over when cookie should and should not be sent, and when setting up cookie, we can now explicitly specify each cookie when the browser adds it to it, for this reason, it introduces the concept of the same site cookie when the browser is on our own domain, and the concept of cross-site cookie when the browser navigates to another domain but sends the request to our domain, for backward compatibility The default setting of cookie for the same site does not change the previous behavior, and if we join this new feature, we need to explicitly set cookie to SameSite = Lax or SameSite = Strict to make it more secure, which has been achieved in .NET Framework and all common browsers, Lax indicates that cookie will be sent to the server during initial navigation, and Strict means that cookie will be sent only if we are already in the domain (that is, sending a second request after the initial navigation). However, this new feature has not been widely adopted (based on Chrome telemetry data in March 2019, only 0.1% of all cookie processed by Chrome worldwide uses the SameSite flag. In order to achieve the goal of promoting this new feature, Google decided to change the default setting of the world's most commonly used browsers: Chrome 80 will need the newly specified setting SameSite = None to maintain the old way of dealing with Cookie. And if we omit the SameSite field as suggested by the old specification, it sets cookie with SameSite = Lax. Note that setting SameSite = None is valid only if cookie is also marked as Secure and a HTTPS connection is required, and more information about SameSite is not covered here. If we have a single-page Web application (SPA) that authenticates through an identity provider hosted on another domain, such as Idp in IdentityServer 4, and the application uses a so-called token refresh, it will be affected. When logging in to IdP, it will set up a session cookie for our users, and the cookie is from the IDP domain at the end of the authentication process. Applications from different domains will receive some kind of access token, these tokens usually have a short life cycle, when the token expires, the application will no longer be able to access the resource server (API). If the user has to log in again every time, the user experience can be different. To prevent this, we can use a refresh token, in which case the application will create an iframe that is invisible to the user. Then start the authentication process again in that iframe, the IdP website has been loaded into the iframe, and if the browser sends the session cookie through IdP, the user will be identified and a new token will be issued. Now, the iframe is in the SPA hosted in the application domain and its content comes from the IDP domain, which will be considered a cross-site request, so if Cookie explicitly indicates that SameSite = None, Chrome 80 will only send that Cookie from iframe to IdP, otherwise Token refresh will be interrupted in Chrome 80. There are also other potential problems. If we embed elements from another domain (such as video) in a Web application or website, and these elements require Cookie to function properly (such as autoplay settings), then these will also need to set up SameSite policies, which are also applicable if our application needs to request a third-party API that relies on Cookie authentication from the browser. We can only change our own server to set the cookie behavior. Explain so much seemingly useless nonsense, in fact, there is a cross-site security policy, that is, the setting of SameSite, such as the exception thrown above, the source is what caused the loss of Cookie in the client? Through the above explanation of Cookie, we can explicitly set the SameSite security policy to ensure whether the Cookie is sent or not. Therefore, I guess whether the security policy of Cookie has been changed in .NET Core 3.x. If the client side is Strict, it will lead to the above exception, such as:

Speaking of which, in order to verify my conclusion, I immediately looked at the setting of the security policy for Cookie in the .NET Core. Do I really use Strict as the default security policy? It turns out that the default option of this security policy is Lax (loose policy), and then we continue to come to the above issue. In 2. 0, we changed Strict to Lax in order to solve the problem of redirected authentication in OAuth.

Although this result is expected, but also unexpected, the children's shoes also encountered the problem of throwing the above exception. I explicitly set the above security policy to Lax, which made me wonder why, I don't know, but it was really solved, and finally the client began to run normally.

Last but not least: IdentityServer4 is HTTPS enabled in the production environment, so if you do not use HTTPS after publishing to the production environment, be sure to explicitly configure the HTTPS option to false, but not locally. If you encounter a problem, analyze the problem first, and then look at the official documentation. If it cannot be solved, you can only analyze the possible causes through experience. I just gave a rough answer to the problem that I need to pay attention to when upgrading IdentityServer4 to the version of .NET Core 3.x. According to my experience, part of the reason is that the concept of official documentation is not explained in detail, and part of the reason is that the built-in processing has been changed due to the version upgrade, but the official document has not been updated. This is the most troublesome problem, which can only be gnawed at the source code and debugged. At the same time, I have updated the IDS4 Demo (which has been released to my github) that I gave when I was founded in Changsha Community to the latest version of .NET Core 3.1.2.

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.