Merge branch 'main' into patch-6

.gitignore

@@ -4,6 +4,7 @@
 # hugo
 public
 root/identityserver/
+.hugo_build.lock
 
 # .net
 [Dd]ebug/

IdentityServer/v5/docs/content/_index.md

@@ -6,6 +6,10 @@ weight: 1
 # Duende IdentityServer v5 Documentation
 The most flexible & standards-compliant OpenID Connect and OAuth 2.0 framework for ASP.NET Core.
 
+{{% notice warning %}}
+Version 5.x out of support since December 13, 2022. We strongly recommend upgrading to a supported version.
+{{% /notice %}}
+
 {{% notice note %}}
-This is the documentation for version 5.x. You can find the v6.x documentation [here](https://docs.duendesoftware.com/identityserver/v6).
+This is the documentation for version 5.x. You can find the v6.x documentation [here](https://docs.duendesoftware.com/identityserver/v6) and the v7.x documentation [here](https://docs.duendesoftware.com/identityserver/v7).
 {{% /notice %}}

IdentityServer/v5/docs/content/apis/_index.md

@@ -11,5 +11,5 @@ Duende IdentityServer issues tokens for accessing resources.
 
 These resources are very often HTTP-based APIs, but could be also other "invokable" functionality like messaging endpoints, gRPC services or even good old XML Web Services. See the [issuing tokens]({{< ref "/tokens" >}}) section on more information on access tokens and how to request them.
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}
 

IdentityServer/v5/docs/content/apis/aspnetcore/_index.md

@@ -7,5 +7,5 @@ chapter = true
 
 # Protecting APIs using ASP.NET Core
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}
 

IdentityServer/v5/docs/content/deployment/_index.md

@@ -9,4 +9,4 @@ chapter = true
 
 Duende IdentityServer is just middleware that you host in ASP.NET Core. All [rules and advice](https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/) around deploying ASP.NET Core applications to various hosting environments apply here too. This section focuses on IdentityServer-specific concerns.
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/diagnostics/_index.md

@@ -7,4 +7,4 @@ chapter = true
 
 # Diagnostics
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/fundamentals/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Fundamentals
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/fundamentals/resources/_index.md

@@ -9,4 +9,4 @@ chapter = true
 
 The ultimate job of Duende IdentityServer is to control access to resources.
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/overview/_index.md

@@ -8,4 +8,4 @@ chapter = true
 # Overview
 
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/quickstarts/_index.md

@@ -9,4 +9,4 @@ chapter = true
 
 The following hands-on tutorials guide you through a couple of common scenarios.
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/_index.md

@@ -7,4 +7,4 @@ chapter = true
 
 # Reference
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/endpoints/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Endpoints
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/endpoints/device_authorization.md

@@ -37,7 +37,7 @@ var client = new HttpClient();
 
 var response = await client.RequestDeviceAuthorizationAsync(new DeviceAuthorizationRequest
 {
-    Address = "https://demo.duendesoftware.com/connect/device_authorize",
+    Address = "https://demo.duendesoftware.com/connect/deviceauthorization",
     ClientId = "device"
 });
-```
+```

IdentityServer/v5/docs/content/reference/models/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Models
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/response_handling/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Response Generators
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/services/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Services
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/stores/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Stores
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/reference/validators/_index.md

@@ -6,4 +6,4 @@ chapter = true
 
 # Validators
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/tokens/_index.md

@@ -9,4 +9,4 @@ chapter = true
 
 At its very heart, Duende IdentityServer is a so-called *Security Token Service* (STS).
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v5/docs/content/tokens/authentication/_index.md

@@ -7,5 +7,5 @@ chapter = true
 
 # Client Authentication
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}
 

IdentityServer/v5/docs/content/upgrades/_index.md

@@ -8,4 +8,4 @@ chapter = true
 
 Here is a list of upgrade guides.
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v6/docs/content/_index.md

@@ -7,5 +7,13 @@ weight: 1
 The most flexible & standards-compliant OpenID Connect and OAuth 2.0 framework for ASP.NET Core.
 
 {{% notice note %}}
-This is the documentation for version 6.x. You can find the v5.x documentation [here](https://docs.duendesoftware.com/identityserver/v5).
+This is the documentation for version 6.x. You can find the v5.x documentation [here](https://docs.duendesoftware.com/identityserver/v5) and the v7.x documentation [here](https://docs.duendesoftware.com/identityserver/v7).
 {{% /notice %}}
+
+{{% notice note %}}
+Version 6.x is supported on .NET 6 and .NET 7. Version 6.x is supported until November 12, 2024 when .NET 6 support ends.
+{{% /notice %}}
+
+{{% notice info %}}
+Version 6.x is supported not supported on .NET 8. Please use [v7.x](https://docs.duendesoftware.com/identityserver/v7) for .NET 8.
+{{% /notice %}}

IdentityServer/v6/docs/content/deployment/_index.md

@@ -22,4 +22,4 @@ Microsoft publishes extensive [advice and documentation](https://docs.microsoft.
 Our experience has been that these topics are very important. Some of our most common support requests are related to [Data Protection]({{<ref "./data_protection">}}) and [Load Balancing]({{<ref "./proxies">}}), so we strongly encourage you to review those pages, along with the rest of this chapter before deploying IdentityServer to production.
 {{% /notice %}}
 
-{{%children style="h4" %}}
+{{%children style="h4" /%}}

IdentityServer/v6/docs/content/fundamentals/keys/automatic_key_management.md

@@ -86,8 +86,8 @@ that should be encrypted at rest. By default, keys managed by Automatic Key
 Management are protected at rest using ASP.NET Core Data Protection. This is
 controlled with the *DataProtectKeys* flag, which is on by default. We recommend
 leaving this flag on unless you are using a custom *ISigningKeyStore* to store
-you keys in a secure location that will ensure keys are encrypted at rest. For
-example, if you implement the *ISigningKeyStore* to store you keys in Azure Key
+your keys in a secure location that will ensure keys are encrypted at rest. For
+example, if you implement the *ISigningKeyStore* to store your keys in Azure Key
 Vault, you could safely disabled *DataProtectKeys*, relying on Azure Key Vault
 to encrypt your signing keys at rest.
 

IdentityServer/v6/docs/content/fundamentals/resources/api_resources.md

@@ -55,7 +55,7 @@ Using the API resource grouping gives you the following additional features
 
 * support for the JWT *aud* claim. The value(s) of the audience claim will be the name of the API resource(s)
 * support for adding common user claims across all contained scopes
-* support for introspection by assigning a API secret to the resource
+* support for introspection by assigning an API secret to the resource
 * support for configuring the access token signing algorithm for the resource
 
 Let's have a look at some example access tokens for the above resource configuration.
@@ -106,7 +106,7 @@ Client requests: **manage**:
 ```
 
 ### Adding user claims
-You can specify that an access token for an API resource (regardless which scope is requested) should contain additional user claims, 
+You can specify that an access token for an API resource (regardless of which scope is requested) should contain additional user claims. 
 
 ```cs
 var customerResource = new ApiResource("customer", "Customer API")
@@ -122,7 +122,7 @@ var customerResource = new ApiResource("customer", "Customer API")
     }
 ```
 
-If a client would now request a scope belonging to the *customer* resource, the access token would contain the additional claims (if provided by your [profile service]({{< ref "/reference/services/profile_service" >}})).
+If a client now requested a scope belonging to the *customer* resource, the access token would contain the additional claims (if provided by your [profile service]({{< ref "/reference/services/profile_service" >}})).
 
 ```json
     {

IdentityServer/v6/docs/content/overview/support.md

@@ -20,4 +20,4 @@ Standard support and feature requests are handled via our public [support forum]
 [Priority support](https://duendesoftware.com/license/PrioritySupportLicense.pdf) is part of our Enterprise Edition. It includes a private email alias, guaranteed two US business days response time.
 
 ### Reporting a security vulnerability
-Security issues and bugs should be reported privately [here](https://duendesoftware.com/contact). You should receive a response within 24 hours.
+Security issues and bugs should be reported privately [here](https://duendesoftware.com/contact). You should receive a response within two business days.

IdentityServer/v6/docs/content/reference/services/interaction_service.md

@@ -170,7 +170,7 @@ The above methods return various models.
 
 * ***SignOutIFrameUrl***
 
-    The URL to render in an *<iframe>* on the logged out page to enable single sign-out.
+    The URL to render in an *\<iframe>* on the logged out page to enable single sign-out.
 
 * ***Parameters***
 

IdentityServer/v6/docs/content/tokens/requesting.md

@@ -44,7 +44,7 @@ Pragma: no-cache
 ```
 
 ### .NET client library
-On .NET you can leverage the [IdentityModel](https://identitymodel.readthedocs.io/en/latest/) client library to [request](https://identitymodel.readthedocs.io/en/latest/client/token.html) tokens.
+In .NET you can leverage the [IdentityModel](https://identitymodel.readthedocs.io/en/latest/) client library to [request](https://identitymodel.readthedocs.io/en/latest/client/token.html) tokens.
 
 The above token request would look like this in C#:
 
@@ -129,7 +129,7 @@ Prerequisites are:
 * grant the client access to both scopes via the [*AllowedScopes*]({{< ref "/reference/models/client#basics" >}}) property
 
 ### Front-channel
-The call to the authorize endpoint is one using a redirect in the browser:
+The call to the authorize endpoint is done using a redirect in the browser:
 
 ```
 GET /connect/authorize?
@@ -179,7 +179,7 @@ Pragma: no-cache
 ```
 
 {{% notice note %}}
-See the refresh token section for more information on how to deal with refresh tokens. TODO link
+See the refresh token section for more information on how to deal with [refresh tokens]({{< ref "/tokens/refresh" >}}).
 {{% /notice %}}
 
 ### .NET client library
@@ -220,4 +220,4 @@ public void ConfigureServices(IServiceCollection services)
 ```
 
 ### Automating token management in ASP.NET Core
-The [IdentityModel.AspNetCore](https://identitymodel.readthedocs.io/en/latest/aspnetcore/web.html) library can also be used to automate token lifetime management in ASP.NET Core applications for you.
+The [IdentityModel.AspNetCore](https://identitymodel.readthedocs.io/en/latest/aspnetcore/web.html) library can also be used to automate token lifetime management in ASP.NET Core applications for you.

IdentityServer/v6/docs/content/ui/_index.md

@@ -7,6 +7,14 @@ chapter = true
 
 # User Interaction and Pages
 
+The design goal of Duende IdentityServer is to supply a full implementation of the OpenID Connect protocol while on the same time be the most flexible and extendible solution. One area that is customized in all deployments of IdentityServer is the user interface. It is typically branded to have the same look and feel as other web sites of the organization. The logic driving the pages is also closely related both to the design and the business rules. To allow full flexibility of the UI, including business rules and user flow, the UI is separated from the core IdentityServer product.
+
+![Overview](images/host.png)
+
+To get a quick start with the UI, we provide a [quick start UI]({{< ref "./../quickstarts/2_interactive#add-the-ui">}}) as well as a [quick start UI adapted to Asp.Net Identity]({{< ref "./../quickstarts/5_aspnetid">}}).
+
+## Required Pages
+
 As browser requests are made to the protocol endpoints in your IdentityServer, they will be redirected to the interactive pages for the user to see. Depending on the features required, the pages expected in your IdentityServer are:
 * [Login]({{< ref "./login" >}}): allows the user to login. This could be achieved with a local credential, or could utilize an external login provider (e.g. social or enterprise federation system).
 * [Logout]({{< ref "./logout" >}}): allows the user to logout (including providing single sign-out).

IdentityServer/v6/docs/content/ui/login/external.md

@@ -127,7 +127,7 @@ For specialized scenarios, you can also short-circuit the external cookie mechan
 On the callback page your typical tasks are:
 
 * Inspect the identity returned by the external provider.
-* Make a decision how you want to deal with that user. This might be different based on the fact if this is a new user or a returning user.
+* Make a decision how you want to deal with that user. This might be different based on if this is a new user or a returning user.
 * New users might need additional steps and UI before they are allowed in. Typically this involves creating a new internal user account that is linked to the user from the external provider.
 * Store the external claims that you want to keep.
 * Delete the temporary cookie.
@@ -188,13 +188,13 @@ await HttpContext.SignOutAsync(IdentityServerConstants.ExternalCookieAuthenticat
 return Redirect(returnUrl);
 ```
 
-Typically, the *sub* value used to login the user would be the user's unique id from your local user database.
+Typically, the *sub* value used to log the user in would be the user's unique id from your local user database.
 
 ## State, URL length, and ISecureDataFormat
 
 When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped.
 This means that state is captured prior to leaving the client and preserved until the user has returned to the client application.
-Many protocols, including OpenID Connect, allow passing some sort of state as a parameter as part of the request, and the identity provider will return that state on the response.
+Many protocols, including OpenID Connect, allow passing some sort of state as a parameter as part of the request, and the identity provider will return that state in the response.
 The OpenID Connect authentication handler provided by ASP.NET Core utilizes this feature of the protocol, and that is how it implements the *returnUrl* feature mentioned above.
 
 The problem with storing state in a request parameter is that the request URL can get too large (over the common limit of 2000 characters).

IdentityServer/v6/docs/content/ui/login/mfa.md

@@ -0,0 +1,12 @@
+---
+title: "Multi Factor Authentication"
+weight: 50
+---
+
+IdentityServer itself doesn't implement MFA. MFA is part of the login which is the [responsibility of the hosting application]({{< ref "..">}}). Microsoft provides some [general guidelines](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/mfa) on how to enable MFA for Asp.Net Core.
+
+## MFA hosted in IdentityServer
+To make the local IdentityServer login page offer MFA anything that works with Asp.Net Core also works with IdentityServer. One approach is to use [Microsoft Asp.Net Identity](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity) that offers [MFA support](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-enable-qrcodes).
+
+## MFA and external authentication
+When using Duende IdentityServer as a [federation gateway](../../federation) the user authentication is done on the upstream provider. It is common to let the upstream provider deal with the entire user authentication, including any MFA required. There's no special configuration or implementation needed on IdentityServer in this case, as the upstream provider handles everyting.

IdentityServer/v6/docs/content/ui/logout/client_redirect.md

@@ -14,4 +14,4 @@ Doing so would skip the necessary [front-channel notifications]({{< ref "./notif
 
 Instead, the typical approach is to render the *PostLogoutRedirectUri* as a link on the "logged out" page.
 This will allow the page to render, the front-channel iframes will load and perform their duty. 
-It's possible to add JavaScript to the page could enhance this experience even more.
+It's possible to add JavaScript to the page to enhance this experience even more.

IdentityServer/v6/docs/content/ui/logout/external.md

@@ -13,7 +13,7 @@ Across this redirect exchange, there will be state that must be maintained so th
 
 ## Determining the Identity Provider
 
-To detect that a user must be redirected to an external identity provider for sign-out is typically done by using a *idp* claim issued into the cookie at IdentityServer.
+To detect that a user must be redirected to an external identity provider for sign-out is typically done by using an *idp* claim issued into the cookie at IdentityServer.
 The value is either *local* for a local sign-in or the scheme of the corresponding authentication handler used for an external provider.
 At sign-out time this claim should be consulted to determine if an external sign-out is required.
 

IdentityServer/v6/docs/content/ui/logout/external_notification.md

@@ -7,8 +7,8 @@ Federated sign-out is the situation where a user has used an external identity p
 When the user signs out, it will be useful for IdentityServer to be notified so that it can sign the user out of IdentityServer and all of the applications that use IdentityServer.
 
 Not all external identity providers support federated sign-out, but those that do will provide a mechanism to notify clients that the user has signed out.
-This notification usually comes in the form of a request in an *<iframe>* from the external identity provider's "logged out" page.
-IdentityServer must then notify all of its clients (as discussed [here]({{< ref "../logout" >}})), also typically in the form of a request in an *<iframe>* from within the external identity provider's *<iframe>*.
+This notification usually comes in the form of a request in an *\<iframe>* from the external identity provider's "logged out" page.
+IdentityServer must then notify all of its clients (as discussed [here]({{< ref "../logout" >}})), also typically in the form of a request in an *\<iframe>* from within the external identity provider's *\<iframe>*.
 
 What makes federated sign-out a special case (when compared to a normal [logout]({{< ref "../logout" >}})) is that the federated sign-out request is not to the normal sign-out endpoint in IdentityServer.
 In fact, each external IdentityProvider will have a different endpoint into your IdentityServer host. 
@@ -19,7 +19,7 @@ which means we are missing the sign-out notifications to IdentityServer's client
 We must add code for each of these federated sign-out endpoints to render the necessary notifications to achieve federated sign-out.
 
 Fortunately IdentityServer already contains this code. 
-When requests come into IdentityServer and invoke the handlers for external authentication providers, IdentityServer detects if these are federated signout requests and if they are it will automatically render the same *<iframe>* as [described here for logout]({{< ref "../logout" >}}).
+When requests come into IdentityServer and invoke the handlers for external authentication providers, IdentityServer detects if these are federated signout requests and if they are it will automatically render the same *\<iframe>* as [described here for logout]({{< ref "../logout" >}}).
 
 
 In short, federated signout is automatically supported.

IdentityServer/v6/docs/content/ui/logout/logout_context.md

@@ -15,7 +15,7 @@ The logout page can be triggered in different ways:
 
 If the login page is being triggered by a protocol workflow, then this means Duende IdentityServer has redirected the user's browser to the logout page.
 In these scenarios, a *logoutId* parameter will be passed that represents the logout context. 
-The *logoutId* value can be exchanged with the *GetLogoutContextAsync* API on the [interaction service]({{<ref "/reference/services/interaction_service">}}) obtain a *LogoutRequest* object.
+The *logoutId* value can be exchanged with the *GetLogoutContextAsync* API on the [interaction service]({{<ref "/reference/services/interaction_service">}}) to obtain a *LogoutRequest* object.
 
 If the page is directly accessed by the user then there will be no *logoutId* parameter, but the context can still be accessed by calling *GetLogoutContextAsync* just without passing any parameters.