Foreword
I have to buy before a course of shoes using the latest version of IdentityServer4 That corresponds .NET Core 3.x, release to manufacturing in the learning environment, the results of a number of issues, I have not had too much attention to IdentityServer4 upgrade version 3.x, in doing so a basic summary might be able to provide a little help for children's shoes appears the same problem.
IdentityServer4 migrate to version 3.x problem
Upgrade for .NET Core 2.x to 3.x would not say more, see the official migration documentation ( https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30 ? View = aspnetcore-tabs = 3.1 & Visual-Studio ), we only introduce changes to the configuration for IdentityServer4 aspects of change
.NET Core Identity
For context inside of Identity] [IdentityDbContext require additional download package] [Microsoft.AspNetCore.Identity.EntityFrameworkCore
OIDC Configuration
OIDC for the following client configuration, you need to download the package] [Microsoft.AspNetCore.Authentication.OpenIdConnect
Authorization middleware configuration
For client authentication and authorization configuration, you need to configure the following authorization middleware (authentication and authorization in no particular order)
Migration class generation
Until we know for migration name is included in the dotnet CLI inside, it has been modified to be carried out by separate package, so we need to download the package] [Microsoft.EntityFrameworkCore.Design, otherwise it will throw an exception as follows
There may be encountered and the current version of the command-line tool inconsistent .NET Core version, updated by the following command
// use PowerShell or CMD command to update // update to the specified version ( 1 ) DOTNET Tool Update - , Ltd. Free Join DOTNET-EF --version 3.1 .2 // update to the latest version ( 2 ) DOTNET Tool Update - , Ltd. Free Join DOTNET-EF
Cookie security policy issues (draw focus)
What might have any problems with the local environment, but to the production environment, may throw the following error, we will look ignorant is not to force it.
warn: Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler[15] '.AspNetCore.Correlation.oidc.x9I39lxuVXliU0_mOAEPEbZy_EPESHQQRvq7LPatX7rv7y_vQi-HKLIwqNacHM62AeKarJVmr_KvjAL7nSX6hdeR' cookie not found. info: Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler[4] Error from RemoteAuthentication: Correlation failed..
This story was born from Cookie's talking about, about the time 20 years ago when designing cookie and the cookie after the redesign, cross-site request forgery (CSRF) attacks, and tracking user is not a big deal, he said in a cookie specification, if set a specific domain cookie, every request sent by the browser to send it to the domain, regardless of whether we navigate directly to the domain only if the browser loads the resource (ie, images) from the field, send a POST request or embed it in part to the iframe, but there is a situation we do not want the browser automatically sends the user's session cookie to the server, as this will allow any website will execute script in the context of the user on the server execution of the request, to avoid this situation, in 2016 drafted SameSite cookie specification, which allows us to better control when to send and should not send cookie, setting cookie, we can now add it to the browser which is explicitly specified for each cookie, to this end, it introduces the same as when the browser is on our own domain Point cookie concept, and when the browser to navigate to another domain but sends a request to the concept of cross-site cookie when our domain, for backward compatibility, the default setting is the same site cookie does not change the previous behavior, if we Join this new feature, you need to explicitly set the cookie SameSite = Lax or SameSite = Strict, to make it more secure, which has been implemented in the .NET Framework and all common browsers, Lax said it would be at the time of cookie initial navigation sent to the server, Strict represents only we have (ie send a second request after the initial navigation) when the domain was sent cookie. But then, this new feature has not been widely adopted by all cookie (based on telemetry data of March 2019 Chrome, Chrome handled on a global scale, only 0.Please note: only if the cookie is marked as Secure and require HTTPS connection, set SameSite = None was effective, where information about SameSite would not elaborate. If we have a one-page Web applications (SPA), the Web application providers (eg IdentityServer 4 in Idp) for authentication hosted on another domain through identity, and the application uses the so-called token refresh, it will be affected, when you log IdP, it sets a session cookie for our users, and the cookie from the IdP domain, at the end of the authentication process, applications from different domains will receive some access token, these tokens are usually not a long life cycle, when the token expires, the application will no longer be able to access the resource server (API), if the user must log in again every time, you can think of poor user experience, in order to prevent this situation we can use the refresh token, in this case, the application will create a user invisible iframe, and then start the authentication process again in an iframe, IdP site is loaded into an iframe, and if the browser via IdP send session cookie, it will identify the user and issues a new token, now, iframe hosted in the application domain SPA Its content from IdP domain, this would be considered cross-site request, so if Cookie clear that SameSite = None, then Chrome 80 only from the Cookie sent to the IdP iframe, otherwise, the token will be refreshed in Chrome 80 interruption occurs. There may also be other potential problems, if we embed elements from another domain (such as video) in a Web application or Web site, and Cookie these elements need to run properly (such as the autoplay settings), then these will be SameSite need to set policy, if our application needs to request dependent on third-party cookie authentication API from a browser, the same applies, we can only change your own server in order to set a cookie behavior.
Seems to explain so many seemingly useless nonsense, in fact, is the emergence of cross-site security policy that is SameSite setting, as an exception thrown, then trace the origin at what caused the loss of the client's Cookie? Through the above explanation of Cookie, we can explicitly set SameSite security policies to ensure that in the end does not send Cookie hair, so I guess .NET Core 3.x is not changed Cookie security policy, if the client is Strict words, that will lead to the occurrence of these abnormalities, such as the following:
Here, in order to verify my conclusion, I immediately look at the .NET Core for the Cookie settings for security policies, it really will be the default Strict security strategy?
The original default security policy is Lax (loose policy), and then continue to the above Issue ( https://github.com/aspnet/Security/issues/1231 ), in 2.0 solved this problem will modify Strict to Lax, it is to solve the problem OAuth authentication redirection jump. This result, although expected, but also unexpected, children's shoes who have encountered problems thrown above, I was explicitly set security policy for the above Lax has been resolved, I was very puzzled, this is why, I do not know, but indeed is resolved, the client is also normal final run up, really (Behind his) face. Finally, equally important is, IdentityServer4 in a production environment is enabled HTTPS, so if not using HTTPS after the release into the production environment, be sure to enable HTTPS option is explicitly configured as false, and the local is not, first of all have problems analysis of the problem, and then look at official documents, should not solve, can only be possible through the analysis of the causes of the experience.
to sum up
本节我只是将IdentityServer4升级到.NET Core 3.x的版本需要注意的问题做了一个粗略的解答，根据我的经验，一部分原因出在对于官方文档概念未详细解导致，另外一部分原因出在由于版本升级导致内置处理出现了更改，但官方文档并未更新，这个最麻烦，出现这样的问题只能硬啃源代码并调试，我也同时将我原先在长沙社区成立时所演讲的IDS4 Demo已更新到了最新.NET Core 3.1.2版本（https://github.com/wangpengxpy/IdentityServer4Sample）。