From b2888bc10e57d87eb12cb5b9f321b31d239d4e81 Mon Sep 17 00:00:00 2001 From: Maarten Balliauw Date: Wed, 8 Jan 2025 12:04:55 +0100 Subject: [PATCH] Fix a bunch of typos --- .../v5/docs/content/fundamentals/resources/isolation.md | 2 +- IdentityServer/v5/docs/content/quickstarts/0_overview.md | 2 +- .../v5/docs/content/quickstarts/1_client_credentials.md | 2 +- .../v5/docs/content/reference/endpoints/end_session.md | 2 +- .../content/reference/services/interaction_service.md | 2 +- IdentityServer/v5/docs/content/ui/login/external.md | 2 +- IdentityServer/v5/docs/content/ui/logout/external.md | 2 +- .../v6/docs/content/deployment/data_protection.md | 2 +- .../v6/docs/content/fundamentals/resources/isolation.md | 2 +- IdentityServer/v6/docs/content/quickstarts/0_overview.md | 2 +- .../v6/docs/content/quickstarts/1_client_credentials.md | 2 +- .../v6/docs/content/quickstarts/2_interactive.md | 2 +- .../v6/docs/content/reference/endpoints/ciba.md | 4 ++-- .../v6/docs/content/reference/endpoints/end_session.md | 2 +- .../content/reference/services/interaction_service.md | 2 +- .../content/reference/validators/dpop_proof_validator.md | 8 ++++---- IdentityServer/v6/docs/content/ui/login/external.md | 2 +- IdentityServer/v6/docs/content/ui/logout/external.md | 2 +- .../v6/docs/content/ui/server_side_sessions/_index.md | 2 +- IdentityServer/v7/docs/content/bff/architecture/_index.md | 2 +- .../v7/docs/content/bff/architecture/ui-hosting.md | 2 +- .../docs/content/bff/extensibility/management/logout.md | 2 +- IdentityServer/v7/docs/content/bff/tokens.md | 2 +- .../v7/docs/content/data/operational/sessions.md | 2 +- .../v7/docs/content/deployment/data_protection.md | 2 +- IdentityServer/v7/docs/content/deployment/proxies.md | 4 ++-- IdentityServer/v7/docs/content/diagnostics/_index.md | 4 ++-- IdentityServer/v7/docs/content/diagnostics/otel/_index.md | 2 +- .../v7/docs/content/fundamentals/resources/isolation.md | 2 +- IdentityServer/v7/docs/content/overview/security.md | 6 +++--- IdentityServer/v7/docs/content/quickstarts/0_overview.md | 2 +- .../v7/docs/content/quickstarts/1_client_credentials.md | 2 +- .../v7/docs/content/quickstarts/2_interactive.md | 2 +- IdentityServer/v7/docs/content/quickstarts/5_aspnetid.md | 2 +- .../v7/docs/content/reference/endpoints/ciba.md | 4 ++-- .../v7/docs/content/reference/endpoints/end_session.md | 2 +- IdentityServer/v7/docs/content/reference/models/client.md | 2 +- .../content/reference/services/interaction_service.md | 2 +- .../content/reference/validators/dpop_proof_validator.md | 8 ++++---- IdentityServer/v7/docs/content/samples/diagnostics.md | 2 +- IdentityServer/v7/docs/content/tokens/internal.md | 2 +- IdentityServer/v7/docs/content/troubleshooting/wilson.md | 2 +- IdentityServer/v7/docs/content/ui/error.md | 2 +- IdentityServer/v7/docs/content/ui/login/external.md | 2 +- IdentityServer/v7/docs/content/ui/logout/external.md | 2 +- .../v7/docs/content/ui/server_side_sessions/_index.md | 2 +- IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md | 6 +++--- 47 files changed, 61 insertions(+), 61 deletions(-) diff --git a/IdentityServer/v5/docs/content/fundamentals/resources/isolation.md b/IdentityServer/v5/docs/content/fundamentals/resources/isolation.md index 07adc991..011deae2 100644 --- a/IdentityServer/v5/docs/content/fundamentals/resources/isolation.md +++ b/IdentityServer/v5/docs/content/fundamentals/resources/isolation.md @@ -105,7 +105,7 @@ redirect_uri=...& resource=urn:invoices ``` -Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another round-trip to the token endpoint. +Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another roundtrip to the token endpoint. ``` POST /token diff --git a/IdentityServer/v5/docs/content/quickstarts/0_overview.md b/IdentityServer/v5/docs/content/quickstarts/0_overview.md index e6ee1b95..054d074c 100644 --- a/IdentityServer/v5/docs/content/quickstarts/0_overview.md +++ b/IdentityServer/v5/docs/content/quickstarts/0_overview.md @@ -4,7 +4,7 @@ date: 2020-09-10T08:22:12+02:00 weight: 1 --- -The quickstarts provide step by step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. +The quickstarts provide step-by-step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. * adding Duende IdentityServer to an ASP.NET Core application * configuring Duende IdentityServer diff --git a/IdentityServer/v5/docs/content/quickstarts/1_client_credentials.md b/IdentityServer/v5/docs/content/quickstarts/1_client_credentials.md index 9a7ce7b1..87882bc2 100644 --- a/IdentityServer/v5/docs/content/quickstarts/1_client_credentials.md +++ b/IdentityServer/v5/docs/content/quickstarts/1_client_credentials.md @@ -4,7 +4,7 @@ date: 2020-09-10T08:22:12+02:00 weight: 2 --- -The following quickstart provides step by step instructions for various common Duende IdentityServer scenarios. +The following quickstart provides step-by-step instructions for various common Duende IdentityServer scenarios. These start with the absolute basics and become more complex as they progress. We recommend that you follow them in sequence. To see the full list, please go to [Quickstarts Overview]({{< ref "0_overview" >}}). diff --git a/IdentityServer/v5/docs/content/reference/endpoints/end_session.md b/IdentityServer/v5/docs/content/reference/endpoints/end_session.md index bb9b8495..0c2da1b6 100644 --- a/IdentityServer/v5/docs/content/reference/endpoints/end_session.md +++ b/IdentityServer/v5/docs/content/reference/endpoints/end_session.md @@ -27,7 +27,7 @@ The URL for the end session endpoint is available via discovery. If a valid *post_logout_redirect_uri* is passed, then the client may also send a *state* parameter. This will be returned back to the client as a query string parameter after the user redirects back to the client. - This is typically used by clients to round-trip state across the redirect. + This is typically used by clients to roundtrip state across the redirect. ``` diff --git a/IdentityServer/v5/docs/content/reference/services/interaction_service.md b/IdentityServer/v5/docs/content/reference/services/interaction_service.md index 689f9d3f..fbd80993 100644 --- a/IdentityServer/v5/docs/content/reference/services/interaction_service.md +++ b/IdentityServer/v5/docs/content/reference/services/interaction_service.md @@ -32,7 +32,7 @@ It is available from the dependency injection system and would normally be injec Used to create a *logoutId* if there is not one presently. This creates a cookie capturing all the current state needed for signout and the *logoutId* identifies that cookie. This is typically used when there is no current *logoutId* and the logout page must capture the current user's state needed for sign-out prior to redirecting to an external identity provider for signout. - The newly created *logoutId* would need to be round-tripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. + The newly created *logoutId* would need to be roundtripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. * ***GrantConsentAsync*** diff --git a/IdentityServer/v5/docs/content/ui/login/external.md b/IdentityServer/v5/docs/content/ui/login/external.md index 418c431a..ddbd4cae 100644 --- a/IdentityServer/v5/docs/content/ui/login/external.md +++ b/IdentityServer/v5/docs/content/ui/login/external.md @@ -192,7 +192,7 @@ Typically, the *sub* value used to login the user would be the user's unique id ## State, URL length, and ISecureDataFormat -When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped. +When redirecting to an external provider for sign-in, frequently state from the client application must be roundtripped. 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. 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. diff --git a/IdentityServer/v5/docs/content/ui/logout/external.md b/IdentityServer/v5/docs/content/ui/logout/external.md index fc5ca76e..568ece55 100644 --- a/IdentityServer/v5/docs/content/ui/logout/external.md +++ b/IdentityServer/v5/docs/content/ui/logout/external.md @@ -45,7 +45,7 @@ public IActionResult Logout(string logoutId) To redirect back to your IdentityServer after the external provider sign-out, the *RedirectUri* should be used on the *AuthenticationProperties* when using ASP.NET Core's *SignOutAsync* API. Recall that after we return, we must perform the other steps to complete the logout workflow. -These steps require the context passed as the *logoutId* parameter, so this state needs to be round-tripped to the external provider. +These steps require the context passed as the *logoutId* parameter, so this state needs to be roundtripped to the external provider. We can do so by incorporating the *logoutId* value into the *RedirectUri*. If there is no *logoutId* parameter on the original logout page request, we still might have context that needs to be round tripped. diff --git a/IdentityServer/v6/docs/content/deployment/data_protection.md b/IdentityServer/v6/docs/content/deployment/data_protection.md index 82083789..6b92a8fc 100644 --- a/IdentityServer/v6/docs/content/deployment/data_protection.md +++ b/IdentityServer/v6/docs/content/deployment/data_protection.md @@ -29,7 +29,7 @@ builder.Services.AddDataProtection() ASP.NET's data protection keys are sometimes confused with IdentityServer's signing keys, but the two are completely separate keys with different purposes. IdentityServer implementations need both to function correctly. #### Data Protection Keys -Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is round-tripped through the browser from being tampered with. +Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is roundtripped through the browser from being tampered with. #### IdentityServer Signing Key Separately, IdentityServer needs cryptographic keys, called [signing keys]({{}}), to sign tokens such as JWT access tokens and id tokens. The signing keys use public key cryptography to allow client applications and APIs to validate token signatures using the public keys, which are published by IdentityServer through [discovery]({{}}). The private key component of the signing keys are also critical secrets for IdentityServer because a valid signature provides integrity and non-repudiation guarantees that allow client applications and APIs to trust those tokens. diff --git a/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md b/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md index 07adc991..011deae2 100644 --- a/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md +++ b/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md @@ -105,7 +105,7 @@ redirect_uri=...& resource=urn:invoices ``` -Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another round-trip to the token endpoint. +Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another roundtrip to the token endpoint. ``` POST /token diff --git a/IdentityServer/v6/docs/content/quickstarts/0_overview.md b/IdentityServer/v6/docs/content/quickstarts/0_overview.md index 7f4e7850..3eaf7867 100644 --- a/IdentityServer/v6/docs/content/quickstarts/0_overview.md +++ b/IdentityServer/v6/docs/content/quickstarts/0_overview.md @@ -5,7 +5,7 @@ date: 2020-09-10T08:22:12+02:00 weight: 1 --- -The quickstarts provide step by step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. +The quickstarts provide step-by-step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. * adding Duende IdentityServer to an ASP.NET Core application * configuring Duende IdentityServer diff --git a/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md b/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md index 40247795..5932aa5d 100644 --- a/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md +++ b/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md @@ -7,7 +7,7 @@ weight: 2 Welcome to the first quickstart for IdentityServer! To see the full list of quickstarts, please see [Quickstarts Overview]({{< ref "0_overview" >}}). -This first quickstart provides step by step instructions to set up +This first quickstart provides step-by-step instructions to set up IdentityServer in the most basic scenario: protecting APIs for server-to-server communication. You will create a solution containing three projects: - An Identity Server diff --git a/IdentityServer/v6/docs/content/quickstarts/2_interactive.md b/IdentityServer/v6/docs/content/quickstarts/2_interactive.md index 78037528..b83b6962 100644 --- a/IdentityServer/v6/docs/content/quickstarts/2_interactive.md +++ b/IdentityServer/v6/docs/content/quickstarts/2_interactive.md @@ -558,7 +558,7 @@ schemes](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?v *AddGoogle* adds the Google scheme, which handles the protocol flow back and forth with Google. After successful login, the application needs to sign in to an additional scheme that can authenticate future requests without needing a -round-trip to Google - typically by issuing a local cookie. The *SignInScheme* +roundtrip to Google - typically by issuing a local cookie. The *SignInScheme* tells the Google handler to use the scheme named *IdentityServerConstants.ExternalCookieAuthenticationScheme*, which is a cookie authentication handler automatically created by IdentityServer that is intended diff --git a/IdentityServer/v6/docs/content/reference/endpoints/ciba.md b/IdentityServer/v6/docs/content/reference/endpoints/ciba.md index 4ebb9b27..6a2085e0 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/ciba.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/ciba.md @@ -22,7 +22,7 @@ The client id and a client credential is required to authenticate to the endpoin * ***login_hint*** - hint for the end user to be authenticated. the value used is implementaiton specific. + hint for the end user to be authenticated. the value used is implementation specific. * ***id_token_hint*** @@ -30,7 +30,7 @@ The client id and a client credential is required to authenticate to the endpoin * ***login_hint_token*** - a token containing information for the end user to be authenticated. the details are implementaiton specific. + a token containing information for the end user to be authenticated. the details are implementation specific. {{% notice note %}} To validate these implementation specific values and use them to identity the user that is to be authenticated, you are required to implement the *IBackchannelAuthenticationUserValidator* interface. diff --git a/IdentityServer/v6/docs/content/reference/endpoints/end_session.md b/IdentityServer/v6/docs/content/reference/endpoints/end_session.md index 037d1740..4780127f 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/end_session.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/end_session.md @@ -27,7 +27,7 @@ The URL for the end session endpoint is available via discovery. If a valid *post_logout_redirect_uri* is passed, then the client may also send a *state* parameter. This will be returned back to the client as a query string parameter after the user redirects back to the client. - This is typically used by clients to round-trip state across the redirect. + This is typically used by clients to roundtrip state across the redirect. ``` diff --git a/IdentityServer/v6/docs/content/reference/services/interaction_service.md b/IdentityServer/v6/docs/content/reference/services/interaction_service.md index b6a9316b..3d0e6cfb 100644 --- a/IdentityServer/v6/docs/content/reference/services/interaction_service.md +++ b/IdentityServer/v6/docs/content/reference/services/interaction_service.md @@ -32,7 +32,7 @@ It is available from the dependency injection system and would normally be injec Used to create a *logoutId* if there is not one presently. This creates a cookie capturing all the current state needed for signout and the *logoutId* identifies that cookie. This is typically used when there is no current *logoutId* and the logout page must capture the current user's state needed for sign-out prior to redirecting to an external identity provider for signout. - The newly created *logoutId* would need to be round-tripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. + The newly created *logoutId* would need to be roundtripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. * ***GrantConsentAsync*** diff --git a/IdentityServer/v6/docs/content/reference/validators/dpop_proof_validator.md b/IdentityServer/v6/docs/content/reference/validators/dpop_proof_validator.md index a2b57262..5930f6da 100644 --- a/IdentityServer/v6/docs/content/reference/validators/dpop_proof_validator.md +++ b/IdentityServer/v6/docs/content/reference/validators/dpop_proof_validator.md @@ -12,11 +12,11 @@ A default implementation is provided and can be overridden as necessary. * ***ValidateAsync*** - Validates a DPoP proof token with the provided *DPoPProofValidatonContext* for the current request. - Returns a *DPoPProofValidatonResult* object. + Validates a DPoP proof token with the provided *DPoPProofValidationContext* for the current request. + Returns a *DPoPProofValidationResult* object. -### DPoPProofValidatonContext +### DPoPProofValidationContext Models the information to validate a DPoP proof token request. * ***Client*** @@ -27,7 +27,7 @@ Models the information to validate a DPoP proof token request. The proof token sent with the request. -### DPoPProofValidatonResult +### DPoPProofValidationResult Models the result of a DPoP proof token validation. * ***IsError*** diff --git a/IdentityServer/v6/docs/content/ui/login/external.md b/IdentityServer/v6/docs/content/ui/login/external.md index 5d5714ca..489d64e3 100644 --- a/IdentityServer/v6/docs/content/ui/login/external.md +++ b/IdentityServer/v6/docs/content/ui/login/external.md @@ -192,7 +192,7 @@ Typically, the *sub* value used to log the user in would be the user's unique id ## State, URL length, and ISecureDataFormat -When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped. +When redirecting to an external provider for sign-in, frequently state from the client application must be roundtripped. 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 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. diff --git a/IdentityServer/v6/docs/content/ui/logout/external.md b/IdentityServer/v6/docs/content/ui/logout/external.md index fc5ca76e..568ece55 100644 --- a/IdentityServer/v6/docs/content/ui/logout/external.md +++ b/IdentityServer/v6/docs/content/ui/logout/external.md @@ -45,7 +45,7 @@ public IActionResult Logout(string logoutId) To redirect back to your IdentityServer after the external provider sign-out, the *RedirectUri* should be used on the *AuthenticationProperties* when using ASP.NET Core's *SignOutAsync* API. Recall that after we return, we must perform the other steps to complete the logout workflow. -These steps require the context passed as the *logoutId* parameter, so this state needs to be round-tripped to the external provider. +These steps require the context passed as the *logoutId* parameter, so this state needs to be roundtripped to the external provider. We can do so by incorporating the *logoutId* value into the *RedirectUri*. If there is no *logoutId* parameter on the original logout page request, we still might have context that needs to be round tripped. diff --git a/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md b/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md index dd45304e..3de4c2a0 100644 --- a/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md +++ b/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md @@ -78,4 +78,4 @@ public void ConfigureServices(IServiceCollection services) The [*IServerSideSessionStore*]({{}}) is the abstraction for storing the server-side session. -A EntityFramework Core implementaiton is already provided as part of our [operational store]({{}}), but you can implement the [interface]({{}}) yourself for other backing implementations. +A EntityFramework Core implementation is already provided as part of our [operational store]({{}}), but you can implement the [interface]({{}}) yourself for other backing implementations. diff --git a/IdentityServer/v7/docs/content/bff/architecture/_index.md b/IdentityServer/v7/docs/content/bff/architecture/_index.md index 73d22145..6978d0ea 100644 --- a/IdentityServer/v7/docs/content/bff/architecture/_index.md +++ b/IdentityServer/v7/docs/content/bff/architecture/_index.md @@ -14,7 +14,7 @@ A BFF host is an ASP.NET Core application with the following components: These components handle OIDC and OAuth protocol requests and responses, manage user sessions and tokens, secure API endpoints for the front end, and optionally serve UI assets. -Duende.BFF builds on widely used tools and frameworks, including ASP.NET Core's OpenID Connect and cookie authentication handlers, YARP, and Duende.AccessTokenManagment. Duende.BFF combines these tools and adds additional security and application features that are useful with a BFF architecture so that you can focus on providing application logic instead of security logic: +Duende.BFF builds on widely used tools and frameworks, including ASP.NET Core's OpenID Connect and cookie authentication handlers, YARP, and Duende.AccessTokenManagement. Duende.BFF combines these tools and adds additional security and application features that are useful with a BFF architecture so that you can focus on providing application logic instead of security logic: ![](../images/DuendeBFF_blocks.png?height=30pc) diff --git a/IdentityServer/v7/docs/content/bff/architecture/ui-hosting.md b/IdentityServer/v7/docs/content/bff/architecture/ui-hosting.md index bf934c61..043b8b97 100644 --- a/IdentityServer/v7/docs/content/bff/architecture/ui-hosting.md +++ b/IdentityServer/v7/docs/content/bff/architecture/ui-hosting.md @@ -23,7 +23,7 @@ dotnet new bfflocalapi ``` #### Host UI in the BFF using Microsoft Templates -Many frontend applications require a build process, which complicates the use of the static file middleware at development time. Visual Studio include's SPA templates that start up a SPA and proxy requests to it during development. Samples of Duende.BFF that take this approach using [React]({{< ref "/samples/bff#reactjs-frontend" >}}) and [Angular]({{< ref "/samples/bff#angular-frontend" >}}) are available. +Many frontend applications require a build process, which complicates the use of the static file middleware at development time. Visual Studio includes SPA templates that start up a SPA and proxy requests to it during development. Samples of Duende.BFF that take this approach using [React]({{< ref "/samples/bff#reactjs-frontend" >}}) and [Angular]({{< ref "/samples/bff#angular-frontend" >}}) are available. Microsoft's templates are easy to use at dev time from Visual Studio. They allow you to simply run the solution, and the template proxies requests to the front end for you. At deploy time, that proxy is removed and the static assets of the site are served by the static file middleware. diff --git a/IdentityServer/v7/docs/content/bff/extensibility/management/logout.md b/IdentityServer/v7/docs/content/bff/extensibility/management/logout.md index 9f679e01..a273c43d 100644 --- a/IdentityServer/v7/docs/content/bff/extensibility/management/logout.md +++ b/IdentityServer/v7/docs/content/bff/extensibility/management/logout.md @@ -5,7 +5,7 @@ date: 2022-12-30 10:55:24 weight: 40 --- -The BFF logout endpoint has extensibility points in two interfaces. The *IlogoutService* is the top level abstraction that processes requests to the endpoint. This service can be used to add custom request processing logic. The *IReturnUrlValidator* ensures that the *returnUrl* parameter passed to the logout endpoint is safe to use. +The BFF logout endpoint has extensibility points in two interfaces. The *ILogoutService* is the top level abstraction that processes requests to the endpoint. This service can be used to add custom request processing logic. The *IReturnUrlValidator* ensures that the *returnUrl* parameter passed to the logout endpoint is safe to use. ## Request Processing *ProcessRequestAsync* is the top level function called in the endpoint service and can be used to add arbitrary logic to the endpoint. diff --git a/IdentityServer/v7/docs/content/bff/tokens.md b/IdentityServer/v7/docs/content/bff/tokens.md index 6a741048..191b37f2 100644 --- a/IdentityServer/v7/docs/content/bff/tokens.md +++ b/IdentityServer/v7/docs/content/bff/tokens.md @@ -84,7 +84,7 @@ public async Task CallApiAsUserTyped( The client will internally always try to use a current and valid access token. If for any reason this is not possible, the 401 status code will be returned to the caller. ### Reuse of Refresh Tokens -We recommend that you configure IdentityServer to issue reusable refresh tokens to BFF clients. Because the BFF is a confidential client, it does not need one-time use refresh tokens. Re-useable refresh tokens are desirable because they avoid performance and user experience problems associated with one time use tokens. See the discussion on [rotating refresh tokens]({{< ref "tokens/refresh#one-time-refresh-tokens" >}}) and the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.2.2) for more details. +We recommend that you configure IdentityServer to issue reusable refresh tokens to BFF clients. Because the BFF is a confidential client, it does not need one-time use refresh tokens. Reusable refresh tokens are desirable because they avoid performance and user experience problems associated with one time use tokens. See the discussion on [rotating refresh tokens]({{< ref "tokens/refresh#one-time-refresh-tokens" >}}) and the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.2.2) for more details. ### Manually revoking refresh tokens Duende.BFF revokes refresh tokens automatically at logout time. This behavior can be disabled with the *RevokeRefreshTokenOnLogout* option. diff --git a/IdentityServer/v7/docs/content/data/operational/sessions.md b/IdentityServer/v7/docs/content/data/operational/sessions.md index 50558f5b..7521c535 100644 --- a/IdentityServer/v7/docs/content/data/operational/sessions.md +++ b/IdentityServer/v7/docs/content/data/operational/sessions.md @@ -11,7 +11,7 @@ The [server-side sessions]({{}}) feature in Duen ## Server-Side Session Store The [IServerSideSessionStore]({{}}) abstracts storing the server-side session data. -[ServerSideSession]({{}}) objects act as the storage entity, and provide several properties uses as metadata for the session. The *Ticket* property contains the actual serailized data used by the ASP.NET Cookie Authentication handler. +[ServerSideSession]({{}}) objects act as the storage entity, and provide several properties uses as metadata for the session. The *Ticket* property contains the actual serialized data used by the ASP.NET Cookie Authentication handler. The methods on the [IServerSideSessionStore]({{}}) are used to orchestrate the various management functions needed by the [server-side sessions]({{}}) feature. diff --git a/IdentityServer/v7/docs/content/deployment/data_protection.md b/IdentityServer/v7/docs/content/deployment/data_protection.md index 82083789..6b92a8fc 100644 --- a/IdentityServer/v7/docs/content/deployment/data_protection.md +++ b/IdentityServer/v7/docs/content/deployment/data_protection.md @@ -29,7 +29,7 @@ builder.Services.AddDataProtection() ASP.NET's data protection keys are sometimes confused with IdentityServer's signing keys, but the two are completely separate keys with different purposes. IdentityServer implementations need both to function correctly. #### Data Protection Keys -Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is round-tripped through the browser from being tampered with. +Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is roundtripped through the browser from being tampered with. #### IdentityServer Signing Key Separately, IdentityServer needs cryptographic keys, called [signing keys]({{}}), to sign tokens such as JWT access tokens and id tokens. The signing keys use public key cryptography to allow client applications and APIs to validate token signatures using the public keys, which are published by IdentityServer through [discovery]({{}}). The private key component of the signing keys are also critical secrets for IdentityServer because a valid signature provides integrity and non-repudiation guarantees that allow client applications and APIs to trust those tokens. diff --git a/IdentityServer/v7/docs/content/deployment/proxies.md b/IdentityServer/v7/docs/content/deployment/proxies.md index 3bf41c00..4013e82b 100644 --- a/IdentityServer/v7/docs/content/deployment/proxies.md +++ b/IdentityServer/v7/docs/content/deployment/proxies.md @@ -20,7 +20,7 @@ The *ForwardedHeaders* middleware reads the information in these headers on inco The appropriate configuration for the forwarded headers middleware depends on your environment. In general, you need to configure which headers it should respect, the IP address or IP address range of your proxy, and the number of proxies you expect (when there are multiple proxies, each one is captured in the X-Forwarded-* headers). There are two ways to configure this middleware: -1. Enable the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED. This is the simplest option, but doesn't give you as much control. It automatically adds the forwarded headers middlware to the pipeline, and configures it to accept forwarded headers from any single proxy, respecting the X-Forwarded-For and X-Forwarded-Proto headers. This is often the right choice for cloud hosted environments and Kubernetes clusters. -2. Configure the *ForwardedHeadersOptions* in DI, and use the ForwardedHeaders middleware explicitly in your pipeline. The advantage of configuring the middleware explicitly is that you can configure it in a way that is appropriate for your environment, if the defaults used by ASPNETCORE_FORWARDEDHEADERS_ENABLED are not what you need. Most notably, you can use the *KnownNetworks* or *KnownProxies* options to only accept headers sent by a known proxy, and you can set the *ForwardLimit* to allow for multiple proxies in front of your IdentityServer. This is often the right choice when you have more complex proxing going on, or if your proxy has a stable IP address. +1. Enable the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED. This is the simplest option, but doesn't give you as much control. It automatically adds the forwarded headers middleware to the pipeline, and configures it to accept forwarded headers from any single proxy, respecting the X-Forwarded-For and X-Forwarded-Proto headers. This is often the right choice for cloud hosted environments and Kubernetes clusters. +2. Configure the *ForwardedHeadersOptions* in DI, and use the ForwardedHeaders middleware explicitly in your pipeline. The advantage of configuring the middleware explicitly is that you can configure it in a way that is appropriate for your environment, if the defaults used by ASPNETCORE_FORWARDEDHEADERS_ENABLED are not what you need. Most notably, you can use the *KnownNetworks* or *KnownProxies* options to only accept headers sent by a known proxy, and you can set the *ForwardLimit* to allow for multiple proxies in front of your IdentityServer. This is often the right choice when you have more complex proxying going on, or if your proxy has a stable IP address. Please consult the Microsoft [documentation](https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer) for more details. \ No newline at end of file diff --git a/IdentityServer/v7/docs/content/diagnostics/_index.md b/IdentityServer/v7/docs/content/diagnostics/_index.md index 659e7d4c..3320413d 100644 --- a/IdentityServer/v7/docs/content/diagnostics/_index.md +++ b/IdentityServer/v7/docs/content/diagnostics/_index.md @@ -5,12 +5,12 @@ weight: 90 --- #### [**Logging**]({{< ref "logging" >}}) -IdentityServer offers multiple diagnostics possibilites. The logs contains detailed information and +IdentityServer offers multiple diagnostics possibilities. The logs contains detailed information and are your best friend when troubleshooting. For security reasons the error messages returned to the UI/client are very brief - the logs always have all the details of what went wrong. #### [**Open Telemetry**]({{< ref "otel" >}}) -Open Telemetry is the new standard way of emiting diagnostics information from a process and +Open Telemetry is the new standard way of emitting diagnostics information from a process and IdentityServer supports Traces (.NET Activities), Metrics and Logs. #### [**Events**]({{< ref "events" >}}) diff --git a/IdentityServer/v7/docs/content/diagnostics/otel/_index.md b/IdentityServer/v7/docs/content/diagnostics/otel/_index.md index 8b26027e..3719dcba 100644 --- a/IdentityServer/v7/docs/content/diagnostics/otel/_index.md +++ b/IdentityServer/v7/docs/content/diagnostics/otel/_index.md @@ -10,7 +10,7 @@ weight: 30 telemetry data (metrics, logs, and traces). This is very useful for analyzing software performance and behavior, especially in highly distributed systems. -.NET 8 comes with first class support for Open Telemetry. IdentityServer emmits traces, metrics and logs. +.NET 8 comes with first class support for Open Telemetry. IdentityServer emits traces, metrics and logs. #### [**Metrics**]({{< ref "metrics">}}) Metrics are high level statistic counters. They provide an aggregated overview and can be used to set monitoring rules. diff --git a/IdentityServer/v7/docs/content/fundamentals/resources/isolation.md b/IdentityServer/v7/docs/content/fundamentals/resources/isolation.md index 07adc991..011deae2 100644 --- a/IdentityServer/v7/docs/content/fundamentals/resources/isolation.md +++ b/IdentityServer/v7/docs/content/fundamentals/resources/isolation.md @@ -105,7 +105,7 @@ redirect_uri=...& resource=urn:invoices ``` -Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another round-trip to the token endpoint. +Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another roundtrip to the token endpoint. ``` POST /token diff --git a/IdentityServer/v7/docs/content/overview/security.md b/IdentityServer/v7/docs/content/overview/security.md index acd481d8..f6d8c284 100644 --- a/IdentityServer/v7/docs/content/overview/security.md +++ b/IdentityServer/v7/docs/content/overview/security.md @@ -88,12 +88,12 @@ wget http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c openssl pkcs7 -inform DER -outform PEM -in SectigoPublicCodeSigningRootR46.p7c -print_certs -out sectigo.pem ``` -Next, you should validate that the thumprint of the certificate is correct. +Next, you should validate that the thumbprint of the certificate is correct. Bootstrapping trust in a certificate chain can be challenging. Fortunately, most desktop environments already trust this certificate, so you can compare the -downloaded certificate's thumprint to the thumbprint of the certificate on a +downloaded certificate's thumbprint to the thumbprint of the certificate on a machine that already trusts it. You should verify this independently, but for -your convenience, the thumprint is +your convenience, the thumbprint is CC:BB:F9:E1:48:5A:F6:3C:E4:7A:BF:8E:9E:64:8C:25:04:FC:31:9D. You can check the thumbprint of the downloaded certificate with openssl: ```sh diff --git a/IdentityServer/v7/docs/content/quickstarts/0_overview.md b/IdentityServer/v7/docs/content/quickstarts/0_overview.md index da0d8305..4db22852 100644 --- a/IdentityServer/v7/docs/content/quickstarts/0_overview.md +++ b/IdentityServer/v7/docs/content/quickstarts/0_overview.md @@ -5,7 +5,7 @@ date: 2020-09-10T08:22:12+02:00 weight: 1 --- -The quickstarts provide step by step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. +The quickstarts provide step-by-step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order. * adding Duende IdentityServer to an ASP.NET Core application * configuring Duende IdentityServer diff --git a/IdentityServer/v7/docs/content/quickstarts/1_client_credentials.md b/IdentityServer/v7/docs/content/quickstarts/1_client_credentials.md index aedddbe2..c50a6be6 100644 --- a/IdentityServer/v7/docs/content/quickstarts/1_client_credentials.md +++ b/IdentityServer/v7/docs/content/quickstarts/1_client_credentials.md @@ -7,7 +7,7 @@ weight: 2 Welcome to the first quickstart for IdentityServer! To see the full list of quickstarts, please see [Quickstarts Overview]({{< ref "0_overview" >}}). -This first quickstart provides step by step instructions to set up +This first quickstart provides step-by-step instructions to set up IdentityServer in the most basic scenario: protecting APIs for server-to-server communication. You will create a solution containing three projects: diff --git a/IdentityServer/v7/docs/content/quickstarts/2_interactive.md b/IdentityServer/v7/docs/content/quickstarts/2_interactive.md index fe6f65a4..98f90f5f 100644 --- a/IdentityServer/v7/docs/content/quickstarts/2_interactive.md +++ b/IdentityServer/v7/docs/content/quickstarts/2_interactive.md @@ -561,7 +561,7 @@ schemes](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?v *AddGoogle* adds the Google scheme, which handles the protocol flow back and forth with Google. After successful login, the application needs to sign in to an additional scheme that can authenticate future requests without needing a -round-trip to Google - typically by issuing a local cookie. The *SignInScheme* +roundtrip to Google - typically by issuing a local cookie. The *SignInScheme* tells the Google handler to use the scheme named *IdentityServerConstants.ExternalCookieAuthenticationScheme*, which is a cookie authentication handler automatically created by IdentityServer that is intended diff --git a/IdentityServer/v7/docs/content/quickstarts/5_aspnetid.md b/IdentityServer/v7/docs/content/quickstarts/5_aspnetid.md index 9fbb4a3d..20e9f84f 100644 --- a/IdentityServer/v7/docs/content/quickstarts/5_aspnetid.md +++ b/IdentityServer/v7/docs/content/quickstarts/5_aspnetid.md @@ -18,7 +18,7 @@ implementation. You will also need to [install the IdentityServer templates]({{< {{% /notice %}} IdentityServer's flexible design allows you to use any database you want to -store users and their data, including password hashes, multifactor +store users and their data, including password hashes, multi-factor authentication details, roles, claims, profile data, etc. If you are starting with a new user database, then ASP.NET Core Identity is one option you could choose. This quickstart shows how to use ASP.NET Core Identity with diff --git a/IdentityServer/v7/docs/content/reference/endpoints/ciba.md b/IdentityServer/v7/docs/content/reference/endpoints/ciba.md index 4ebb9b27..6a2085e0 100644 --- a/IdentityServer/v7/docs/content/reference/endpoints/ciba.md +++ b/IdentityServer/v7/docs/content/reference/endpoints/ciba.md @@ -22,7 +22,7 @@ The client id and a client credential is required to authenticate to the endpoin * ***login_hint*** - hint for the end user to be authenticated. the value used is implementaiton specific. + hint for the end user to be authenticated. the value used is implementation specific. * ***id_token_hint*** @@ -30,7 +30,7 @@ The client id and a client credential is required to authenticate to the endpoin * ***login_hint_token*** - a token containing information for the end user to be authenticated. the details are implementaiton specific. + a token containing information for the end user to be authenticated. the details are implementation specific. {{% notice note %}} To validate these implementation specific values and use them to identity the user that is to be authenticated, you are required to implement the *IBackchannelAuthenticationUserValidator* interface. diff --git a/IdentityServer/v7/docs/content/reference/endpoints/end_session.md b/IdentityServer/v7/docs/content/reference/endpoints/end_session.md index 037d1740..4780127f 100644 --- a/IdentityServer/v7/docs/content/reference/endpoints/end_session.md +++ b/IdentityServer/v7/docs/content/reference/endpoints/end_session.md @@ -27,7 +27,7 @@ The URL for the end session endpoint is available via discovery. If a valid *post_logout_redirect_uri* is passed, then the client may also send a *state* parameter. This will be returned back to the client as a query string parameter after the user redirects back to the client. - This is typically used by clients to round-trip state across the redirect. + This is typically used by clients to roundtrip state across the redirect. ``` diff --git a/IdentityServer/v7/docs/content/reference/models/client.md b/IdentityServer/v7/docs/content/reference/models/client.md index 5c7a1dea..9f49c227 100644 --- a/IdentityServer/v7/docs/content/reference/models/client.md +++ b/IdentityServer/v7/docs/content/reference/models/client.md @@ -300,7 +300,7 @@ Settings specific to the Demonstration of Proof-of-Possession at the Application * ***RequireDPoP*** - Specifies whether a DPoP (Demonstrating Proof-of-Possession) token is requied to be used by this client. Defaults to *false*. + Specifies whether a DPoP (Demonstrating Proof-of-Possession) token is required to be used by this client. Defaults to *false*. * ***DPoPValidationMode*** diff --git a/IdentityServer/v7/docs/content/reference/services/interaction_service.md b/IdentityServer/v7/docs/content/reference/services/interaction_service.md index b6a9316b..3d0e6cfb 100644 --- a/IdentityServer/v7/docs/content/reference/services/interaction_service.md +++ b/IdentityServer/v7/docs/content/reference/services/interaction_service.md @@ -32,7 +32,7 @@ It is available from the dependency injection system and would normally be injec Used to create a *logoutId* if there is not one presently. This creates a cookie capturing all the current state needed for signout and the *logoutId* identifies that cookie. This is typically used when there is no current *logoutId* and the logout page must capture the current user's state needed for sign-out prior to redirecting to an external identity provider for signout. - The newly created *logoutId* would need to be round-tripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. + The newly created *logoutId* would need to be roundtripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page. * ***GrantConsentAsync*** diff --git a/IdentityServer/v7/docs/content/reference/validators/dpop_proof_validator.md b/IdentityServer/v7/docs/content/reference/validators/dpop_proof_validator.md index a2b57262..5930f6da 100644 --- a/IdentityServer/v7/docs/content/reference/validators/dpop_proof_validator.md +++ b/IdentityServer/v7/docs/content/reference/validators/dpop_proof_validator.md @@ -12,11 +12,11 @@ A default implementation is provided and can be overridden as necessary. * ***ValidateAsync*** - Validates a DPoP proof token with the provided *DPoPProofValidatonContext* for the current request. - Returns a *DPoPProofValidatonResult* object. + Validates a DPoP proof token with the provided *DPoPProofValidationContext* for the current request. + Returns a *DPoPProofValidationResult* object. -### DPoPProofValidatonContext +### DPoPProofValidationContext Models the information to validate a DPoP proof token request. * ***Client*** @@ -27,7 +27,7 @@ Models the information to validate a DPoP proof token request. The proof token sent with the request. -### DPoPProofValidatonResult +### DPoPProofValidationResult Models the result of a DPoP proof token validation. * ***IsError*** diff --git a/IdentityServer/v7/docs/content/samples/diagnostics.md b/IdentityServer/v7/docs/content/samples/diagnostics.md index f912a2b7..eec022bc 100644 --- a/IdentityServer/v7/docs/content/samples/diagnostics.md +++ b/IdentityServer/v7/docs/content/samples/diagnostics.md @@ -7,7 +7,7 @@ weight: 50 ### OpenTelemetry with Aspire [link to source code]({{< param samples_base >}}/Diagnostics/Aspire) -IdentityServer emits OpenTelemetry metcis, traces and logs (see [here]({{< ref "/diagnostics/otel" >}}) for more information). This sample uses .NET Aspire to +IdentityServer emits OpenTelemetry metrics, traces and logs (see [here]({{< ref "/diagnostics/otel" >}}) for more information). This sample uses .NET Aspire to display OpenTelemetry data. The solution contains an IdentityServer host, an API and a web client. The access token lifetime is set to a very small value to force frequent refresh token flows. diff --git a/IdentityServer/v7/docs/content/tokens/internal.md b/IdentityServer/v7/docs/content/tokens/internal.md index c5144dca..ac5fbf4a 100644 --- a/IdentityServer/v7/docs/content/tokens/internal.md +++ b/IdentityServer/v7/docs/content/tokens/internal.md @@ -31,4 +31,4 @@ public async Task MyAction() } ``` -The *IIdentityServerTools* interface was added in v7 to allow mocking. Previous versions refrenced the *IdentityServerTools* implementation class directly. \ No newline at end of file +The *IIdentityServerTools* interface was added in v7 to allow mocking. Previous versions referenced the *IdentityServerTools* implementation class directly. \ No newline at end of file diff --git a/IdentityServer/v7/docs/content/troubleshooting/wilson.md b/IdentityServer/v7/docs/content/troubleshooting/wilson.md index 1fb4faa4..5009734d 100644 --- a/IdentityServer/v7/docs/content/troubleshooting/wilson.md +++ b/IdentityServer/v7/docs/content/troubleshooting/wilson.md @@ -3,7 +3,7 @@ title = "Microsoft.IdentityModel.* versions" weight = 10 +++ -Duende IdentityServer, the Microsoft external authentication handlers and other libraries all use the Microsoft.IdentityModel set of libraries. These libraries provides token and configuration handling features. The functionality is split up between different libraries and they all need to be **exactly the same version**. However this is not enfored by Nuget so it is common to end up with an application that brings in different versions of Microsoft.IdentityModel.* through transitive dependencies. +Duende IdentityServer, the Microsoft external authentication handlers and other libraries all use the Microsoft.IdentityModel set of libraries. These libraries provides token and configuration handling features. The functionality is split up between different libraries and they all need to be **exactly the same version**. However this is not enforced by Nuget so it is common to end up with an application that brings in different versions of Microsoft.IdentityModel.* through transitive dependencies. ## Known Errors Errors that we have seen because of IdentityModel version mismatches include: diff --git a/IdentityServer/v7/docs/content/ui/error.md b/IdentityServer/v7/docs/content/ui/error.md index fab70df7..f12db256 100644 --- a/IdentityServer/v7/docs/content/ui/error.md +++ b/IdentityServer/v7/docs/content/ui/error.md @@ -4,7 +4,7 @@ date: 2020-09-10T08:22:12+02:00 weight: 30 --- -The error page is used to display to the end user that an error has ocurred during a request to the [authorize endpoint]({{}}). +The error page is used to display to the end user that an error has occurred during a request to the [authorize endpoint]({{}}). When an error occurs, IdentityServer will redirect the user to a configurable *ErrorUrl*. ```csharp diff --git a/IdentityServer/v7/docs/content/ui/login/external.md b/IdentityServer/v7/docs/content/ui/login/external.md index 5f59f7ab..2b1a7ea9 100644 --- a/IdentityServer/v7/docs/content/ui/login/external.md +++ b/IdentityServer/v7/docs/content/ui/login/external.md @@ -189,7 +189,7 @@ Typically, the *sub* value used to log the user in would be the user's unique id ## State, URL length, and ISecureDataFormat -When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped. +When redirecting to an external provider for sign-in, frequently state from the client application must be roundtripped. 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 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. diff --git a/IdentityServer/v7/docs/content/ui/logout/external.md b/IdentityServer/v7/docs/content/ui/logout/external.md index fc5ca76e..568ece55 100644 --- a/IdentityServer/v7/docs/content/ui/logout/external.md +++ b/IdentityServer/v7/docs/content/ui/logout/external.md @@ -45,7 +45,7 @@ public IActionResult Logout(string logoutId) To redirect back to your IdentityServer after the external provider sign-out, the *RedirectUri* should be used on the *AuthenticationProperties* when using ASP.NET Core's *SignOutAsync* API. Recall that after we return, we must perform the other steps to complete the logout workflow. -These steps require the context passed as the *logoutId* parameter, so this state needs to be round-tripped to the external provider. +These steps require the context passed as the *logoutId* parameter, so this state needs to be roundtripped to the external provider. We can do so by incorporating the *logoutId* value into the *RedirectUri*. If there is no *logoutId* parameter on the original logout page request, we still might have context that needs to be round tripped. diff --git a/IdentityServer/v7/docs/content/ui/server_side_sessions/_index.md b/IdentityServer/v7/docs/content/ui/server_side_sessions/_index.md index 103faeda..7d4f94c6 100644 --- a/IdentityServer/v7/docs/content/ui/server_side_sessions/_index.md +++ b/IdentityServer/v7/docs/content/ui/server_side_sessions/_index.md @@ -74,4 +74,4 @@ builder.Services.AddIdentityServer(options => { The [*IServerSideSessionStore*]({{}}) is the abstraction for storing the server-side session. -A EntityFramework Core implementaiton is already provided as part of our [operational store]({{}}), but you can implement the [interface]({{}}) yourself for other backing implementations. +A EntityFramework Core implementation is already provided as part of our [operational store]({{}}), but you can implement the [interface]({{}}) yourself for other backing implementations. diff --git a/IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md b/IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md index 4e75529b..123b2935 100644 --- a/IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md +++ b/IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md @@ -104,9 +104,9 @@ Some organizations prefer to use other tools for managing schema changes. You're #### Only impacts particular customizations or edge cases - The *DefaultCorsPolicyService* now depends on the *IConfigurationDbContext* directly, instead of taking a dependency on the *IServiceProvider* and resolving that DbContext from it. If you have a customized CORS implementation that derives from the *DefaultCorsPolicyService*, you need to update the constructor of your derived class to use the *IConfigurationDbContext*. -- The *DPoPProofValidatonContext* has been refactored. Instead of the *Client* property, we now put the relevant details (expiration validation mode and clock skew) directly in the context. We also have added the HTTP method and URL to the context. If you have a custom implementation of the *IDPoPProofValidator* or a class that derives from the *DefaultDPoPProofValidator*, update your usage of the context appropriately. +- The *DPoPProofValidationContext* has been refactored. Instead of the *Client* property, we now put the relevant details (expiration validation mode and clock skew) directly in the context. We also have added the HTTP method and URL to the context. If you have a custom implementation of the *IDPoPProofValidator* or a class that derives from the *DefaultDPoPProofValidator*, update your usage of the context appropriately. - The *DefaultTokenService* no longer includes an *IHttpContextAccessor*. This member was unused by the default implementation and marked as obsolete. Customizations that derive from the *DefaultTokenService* no longer need to pass the accessor to the base constructor. If such a customization needs the accessor, add it to the derived class. -- The *ValidatedAuthorizeRequest.RequestedResourceIndiators* property was misspelled and has been renamed *RequestedResourceIndicators*. +- The *ValidatedAuthorizeRequest.RequestedResourceIndicators* property was misspelled and has been renamed *RequestedResourceIndicators*. - The reference token store now includes the session id when revoking reference tokens. Implementors of *IReferenceTokenStore* should update their implementation of token revocation to include the session id. - Invalid prompt modes now cause validation errors that result in an HTTP 400 (Bad Request). Previously, invalid prompt modes were ignored. This complies with updates to the OpenID Connect specification. - A new interface *IIdentityServerTools* has been introduced for the *IdentityServerTools* helper class to allow mocking. Update any direct references to *IdentityServerTools* to *IIdentityServerTools*. @@ -144,4 +144,4 @@ That's it. Of course, at this point you can and should test that your IdentitySe You are now done with everything related to the IdentityServer upgrade, but we would also like to add a references to breaking changes in .NET 8 and associated libraries that are likely to affect the IdentityServer setup. - Entity Framework Core 8 has some performance improvements in the query generation for Microsoft SQL Server that relies on database features that requires a database compatibility level of at least 130. This can cause errors on database access like *Microsoft.Data.SqlClient.SqlException (0x80131904): The syntax near '$' is incorrect.* or *Microsoft.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near the keyword 'WITH'.* Please see https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/breaking-changes#mitigations for more information. - For container deployments, the [default ASP.NET Core port changed from 80 to 8080](https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port). This might require configuration updates to either continue using port 80 or to migrate to using 8080. - - IdentityServer and the Asp.Net Authentication packages all depends on the *Microsoft.IdentityModel.** packages. With packages that are brought in as transient dependencies there is less control of the versions being pulled in. If different packages from the *Microsoft.IdentityModel.** family end up having different versions, there will be odd bugs. We've seen reports where the refresh token isn't stored and where the OIDC handler fails to redirect to an OIDC Provider because it failed reading the discovyer document. **Always ensure that all Microsoft.IdentityModel.\* packages are of exactly the same version**. If they are not, you might need to make an explicit ** to pin an exact version. \ No newline at end of file + - IdentityServer and the Asp.Net Authentication packages all depends on the *Microsoft.IdentityModel.** packages. With packages that are brought in as transient dependencies there is less control of the versions being pulled in. If different packages from the *Microsoft.IdentityModel.** family end up having different versions, there will be odd bugs. We've seen reports where the refresh token isn't stored and where the OIDC handler fails to redirect to an OIDC Provider because it failed reading the discovery document. **Always ensure that all Microsoft.IdentityModel.\* packages are of exactly the same version**. If they are not, you might need to make an explicit ** to pin an exact version. \ No newline at end of file