diff --git a/src/content/docs/accesstokenmanagement/advanced/client-credentials.md b/src/content/docs/accesstokenmanagement/advanced/client-credentials.md index fdd7863ae..fd83ca1f8 100644 --- a/src/content/docs/accesstokenmanagement/advanced/client-credentials.md +++ b/src/content/docs/accesstokenmanagement/advanced/client-credentials.md @@ -12,7 +12,7 @@ The most common way to use the access token management for machine to machine co ## Client options -You can add token client definitions to your host while configuring the DI container, e.g.: +You can add token client definitions to your host while configuring the ASP.NET Core service provider, e.g.: ```cs services.AddClientCredentialsTokenManagement() @@ -53,7 +53,7 @@ services.Configure("invoices", client => }); ``` -Or use the `IConfigureNamedOptions` if you need access to the DI container during registration, e.g.: +Or use the `IConfigureNamedOptions` if you need access to the ASP.NET Core service provider during registration, e.g.: ```cs public class ClientCredentialsClientConfigureOptions : IConfigureNamedOptions diff --git a/src/content/docs/accesstokenmanagement/advanced/user-tokens.md b/src/content/docs/accesstokenmanagement/advanced/user-tokens.md index f00aaa8ad..58e304b5b 100644 --- a/src/content/docs/accesstokenmanagement/advanced/user-tokens.md +++ b/src/content/docs/accesstokenmanagement/advanced/user-tokens.md @@ -12,7 +12,7 @@ The most common way to use the access token management for interactive web appli ## General options -You can pass in some global options when registering token management in DI. +You can pass in some global options when registering token management in the ASP.NET Core service provider. * `ChallengeScheme` - by default the OIDC configuration is inferred from the default challenge scheme. This is recommended approach. If for some reason your OIDC handler is not the default challenge scheme, you can set the scheme name on the options * `UseChallengeSchemeScopedTokens` - the general assumption is that you only have one OIDC handler configured. If that is not the case, token management needs to maintain multiple sets of token artefacts simultaneously. You can opt in to that feature using this setting. diff --git a/src/content/docs/accesstokenmanagement/blazor-server.md b/src/content/docs/accesstokenmanagement/blazor-server.md index a262358f8..ef317d9e1 100644 --- a/src/content/docs/accesstokenmanagement/blazor-server.md +++ b/src/content/docs/accesstokenmanagement/blazor-server.md @@ -21,9 +21,9 @@ Fortunately, Duende.AccessTokenManagement provides a straightforward solution to Since the tokens cannot be managed in the authentication session, you need to store them somewhere else. The options include an in-memory data structure, a distributed cache like redis, or a database. Duende.AccessTokenManagement describes this store for tokens with the *IUserTokenStore* interface. In non-blazor scenarios, the default implementation that stores the tokens in the session is used. In your Blazor server application, you'll need to decide where you want to store the tokens and implement the store interface. -The store interface is very simple. `StoreTokenAsync` adds a token to the store for a particular user, `GetTokenAsync` retrieves the user's token, and *ClearTokenAsync* clears the tokens stored for a particular user. A sample implementation that stores the tokens in memory can be found in the *ServerSideTokenStore* in the [*BlazorServer* sample](https://github.com/DuendeSoftware/foss/tree/main/access-token-management/samples/BlazorServer). +The store interface is straightforward. `StoreTokenAsync` adds a token to the store for a particular user, `GetTokenAsync` retrieves the user's token, and *ClearTokenAsync* clears the tokens stored for a particular user. A sample implementation that stores the tokens in memory can be found in the *ServerSideTokenStore* in the [*BlazorServer* sample](https://github.com/DuendeSoftware/foss/tree/main/access-token-management/samples/BlazorServer). -Register your token store in the DI container and tell Duende.AccessTokenManagement to integrate with Blazor by calling `AddBlazorServerAccessTokenManagement`: +Register your token store in the ASP.NET Core service provider and tell Duende.AccessTokenManagement to integrate with Blazor by calling `AddBlazorServerAccessTokenManagement`: ```cs builder.Services.AddOpenIdConnectAccessTokenManagement() @@ -64,7 +64,7 @@ Once registered and initialized, Duende.AccessTokenManagement will keep the stor ## Retrieving And Using Tokens -If you've registered your token store with `AddBlazorServerAccessTokenManagement`, Duende.AccessTokenManagement will register the services necessary to attach tokens to outgoing HTTP requests automatically, using the same API as a non-blazor application. You inject an HTTP client factory and resolve named HTTP clients where ever you need to make HTTP requests, and you register the HTTP client's that use access tokens in the DI system with our extension method: +If you've registered your token store with `AddBlazorServerAccessTokenManagement`, Duende.AccessTokenManagement will register the services necessary to attach tokens to outgoing HTTP requests automatically, using the same API as a non-blazor application. You inject an HTTP client factory and resolve named HTTP clients where ever you need to make HTTP requests, and you register the HTTP client's that use access tokens in the ASP.NET Core service provider with our extension method: ```cs builder.Services.AddUserAccessTokenHttpClient("demoApiClient", configureClient: client => diff --git a/src/content/docs/accesstokenmanagement/web-apps.md b/src/content/docs/accesstokenmanagement/web-apps.md index 41191403f..abb4ed8be 100644 --- a/src/content/docs/accesstokenmanagement/web-apps.md +++ b/src/content/docs/accesstokenmanagement/web-apps.md @@ -176,7 +176,7 @@ public async Task CallApi() ### HTTP Client Factory -Last but not least, if you registered clients with the factory, you can simply use them. They will try to make sure that a current access token is always sent along. If that is not possible, ultimately a 401 will be returned to the calling code. +Last but not least, if you registered clients with the factory, you can use them. They will try to make sure that a current access token is always sent along. If that is not possible, ultimately a 401 will be returned to the calling code. ```cs public async Task CallApi() diff --git a/src/content/docs/accesstokenmanagement/workers.md b/src/content/docs/accesstokenmanagement/workers.md index c7e05838c..8ed49a9ee 100644 --- a/src/content/docs/accesstokenmanagement/workers.md +++ b/src/content/docs/accesstokenmanagement/workers.md @@ -19,7 +19,7 @@ Have a look for the `Worker` project in the [samples folder](https://github.com/ Start by adding a reference to the `Duende.AccessTokenManagement` NuGet package to your application. -You can add the necessary services to the DI system by calling `AddClientCredentialsTokenManagement()`. After that you can add one or more named client definitions by calling `AddClient`. +You can add the necessary services to the ASP.NET Core service provider by calling `AddClientCredentialsTokenManagement()`. After that you can add one or more named client definitions by calling `AddClient`. ```cs // default cache diff --git a/src/content/docs/bff/architecture/ui-hosting.md b/src/content/docs/bff/architecture/ui-hosting.md index df4c4674b..63a55f2b8 100644 --- a/src/content/docs/bff/architecture/ui-hosting.md +++ b/src/content/docs/bff/architecture/ui-hosting.md @@ -47,7 +47,7 @@ development time. Visual Studio includes SPA templates that start up a SPA and p Samples of Duende.BFF that take this approach using [React](/bff/samples#reactjs-frontend) and [Angular](/bff/samples#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 +Microsoft's templates are easy-to-use at dev time from Visual Studio. They allow you to 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/src/content/docs/bff/fundamentals/options.md b/src/content/docs/bff/fundamentals/options.md index 549fee7e0..a845a40a6 100644 --- a/src/content/docs/bff/fundamentals/options.md +++ b/src/content/docs/bff/fundamentals/options.md @@ -97,7 +97,7 @@ builder.Services.AddBff(options => * ***EnableSessionCleanup*** Indicates if expired server side sessions should be cleaned up. - This requires an implementation of IUserSessionStoreCleanup to be registered in the DI system. + This requires an implementation of IUserSessionStoreCleanup to be registered in the ASP.NET Core service provider. Defaults to *false*. * ***SessionCleanupInterval*** diff --git a/src/content/docs/bff/fundamentals/session/management/index.md b/src/content/docs/bff/fundamentals/session/management/index.md index fec464b74..606df88ab 100644 --- a/src/content/docs/bff/fundamentals/session/management/index.md +++ b/src/content/docs/bff/fundamentals/session/management/index.md @@ -16,7 +16,7 @@ Duende.BFF adds endpoints for performing typical session-management operations s In addition, Duende.BFF adds an implementation of the OpenID Connect back-channel notification endpoint to overcome the restrictions of third party cookies in front-channel notification in modern browsers. -You enable the endpoints by adding the relevant services into the DI container: +You enable the endpoints by adding the relevant services into the ASP.NET Core service provider: ```csharp // Program.cs diff --git a/src/content/docs/bff/fundamentals/session/management/silent-login.md b/src/content/docs/bff/fundamentals/session/management/silent-login.md index e1faa57ff..5391bc305 100644 --- a/src/content/docs/bff/fundamentals/session/management/silent-login.md +++ b/src/content/docs/bff/fundamentals/session/management/silent-login.md @@ -21,7 +21,7 @@ The expected usage pattern is that the application code loads in the browser and This non-interactive design relies upon the use of an *iframe* to make the silent login request. The result of the silent login request in the *iframe* will then use *postMessage* to notify the parent window of the outcome. -If the result is that a session has been established, then the application logic can either re-trigger a call to the *User Endpoint*, or simply reload the entire page (depending on the preferred design). If the result is that a session has not been established, then the application redirects to the login endpoint to log the user in interactively. +If the result is that a session has been established, then the application logic can either re-trigger a call to the *User Endpoint*, or reload the entire page (depending on the preferred design). If the result is that a session has not been established, then the application redirects to the login endpoint to log the user in interactively. To trigger the silent login, the application code must have an *iframe* and then set its *src* to the silent login endpoint. For example in your HTML: diff --git a/src/content/docs/bff/fundamentals/session/server-side-sessions.md b/src/content/docs/bff/fundamentals/session/server-side-sessions.md index 90e8d623d..9757dd992 100644 --- a/src/content/docs/bff/fundamentals/session/server-side-sessions.md +++ b/src/content/docs/bff/fundamentals/session/server-side-sessions.md @@ -61,7 +61,7 @@ builder.Services.AddBff(options => { .AddServerSideSessions(); ``` -This requires an implementation of [*IUserSessionStoreCleanup*](/bff/extensibility/sessions#user-session-store-cleanup) in the DI system. +This requires an implementation of [*IUserSessionStoreCleanup*](/bff/extensibility/sessions#user-session-store-cleanup) in the ASP.NET Core service provider. If using Entity Framework Core, then the *IUserSessionStoreCleanup* implementation is provided for you when you use *AddEntityFrameworkServerSideSessions*. Just enable session cleanup: diff --git a/src/content/docs/bff/upgrading/bff-v2-to-v3.md b/src/content/docs/bff/upgrading/bff-v2-to-v3.md index 16628e835..22c449f38 100644 --- a/src/content/docs/bff/upgrading/bff-v2-to-v3.md +++ b/src/content/docs/bff/upgrading/bff-v2-to-v3.md @@ -57,7 +57,7 @@ Here are common scenario's for implementing your own *IHttpTransformerFactory* a If you used a custom implementation of `IHttpTransformerFactory` to change the default behavior of `MapRemoteBffApiEndpoint()`, -for example to add additional transforms, then you can now inject a custom delegate into the DI container: +for example to add additional transforms, then you can now inject a custom delegate into the ASP.NET Core service provider: ```csharp services.AddSingleton(CustomDefaultYarpTransforms); diff --git a/src/content/docs/identitymodel/endpoints/discovery.md b/src/content/docs/identitymodel/endpoints/discovery.md index de20ddf79..d807a8bd8 100644 --- a/src/content/docs/identitymodel/endpoints/discovery.md +++ b/src/content/docs/identitymodel/endpoints/discovery.md @@ -129,19 +129,16 @@ var disco = await cache.GetAsync(); if (disco.IsError) throw new Exception(disco.Error); ``` -You can specify the cache duration using the `CacheDuration` property -and also specify a custom discovery policy by passing in a -`DiscoveryPolicy` to the constructor. +You can specify the cache duration using the `CacheDuration` property and also specify a custom discovery policy by +passing in a `DiscoveryPolicy` to the constructor. ### Caching And HttpClient Instances -By default, the discovery cache will create a new instance of -`HttpClient` every time it needs to access the discovery endpoint. You -can modify this behavior in two ways, either by passing in a pre-created -instance into the constructor, or by providing a function that will -return an `HttpClient` when needed. +By default, the discovery cache will create a new instance of `HttpClient` every time it needs to access the discovery +endpoint. You can modify this behavior in two ways, either by passing in a pre-created instance into the constructor, +or by providing a function that will return an `HttpClient` when needed. -The following code will set up the discovery cache in DI and will use the +The following code will set up the discovery cache in the ASP.NET Core service provider and will use the `HttpClientFactory` to create clients: ```csharp diff --git a/src/content/docs/identityserver/aspnet-identity.md b/src/content/docs/identityserver/aspnet-identity.md index 7e49c09b0..761212206 100644 --- a/src/content/docs/identityserver/aspnet-identity.md +++ b/src/content/docs/identityserver/aspnet-identity.md @@ -39,9 +39,9 @@ builder.Services.AddIdentityServer() This configures IdentityServer to use the ASP.NET Identity implementations of [IUserClaimsPrincipalFactory](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.iuserclaimsprincipalfactory-1) to convert the user data into claims, `IResourceOwnerPasswordValidator` to support the [password grant type](/identityserver/tokens/password-grant/), and `IProfileService` which uses the `IUserClaimsPrincipalFactory` to add [claims](/identityserver/fundamentals/claims) to tokens. It also configures some of ASP.NET Identity's options for use with IdentityServer (such as claim types to use and authentication cookie settings). -If you need to use your own implementation of `IUserClaimsPrincipalFactory`, then that is supported. Our implementation of the `IUserClaimsPrincipalFactory` will use the decorator pattern to encapsulate yours. For this to work properly, ensure that your implementation is registered in the DI system prior to calling the IdentityServer `AddAspNetIdentity` extension method. +If you need to use your own implementation of `IUserClaimsPrincipalFactory`, then that is supported. Our implementation of the `IUserClaimsPrincipalFactory` will use the decorator pattern to encapsulate yours. For this to work properly, ensure that your implementation is registered in the ASP.NET Core service provider prior to calling the IdentityServer `AddAspNetIdentity` extension method. -The `IUserProfileService` interface has two methods that IdentityServer uses to interact with the user store. The profile service added for ASP.NET Identity implements `GetProfileDataAsync` by invoking the `IUserClaimsPrincipalFactory` implementation registered in the dependency injection container. The other method on `IProfileService` is `IsActiveAsync` which is used in various places in IdentityServer to validate that the user is (still) active. There is no built-in concept in ASP.NET Identity to inactive users, so our implementation is simply hard coded to return `true`. If you extend the ASP.NET Identity user with enabled/disabled functionality you should derive from our `ProfileService` and override *IsUserActiveAsync(TUser user)* to check your custom enabled/disabled flags. +The `IUserProfileService` interface has two methods that IdentityServer uses to interact with the user store. The profile service added for ASP.NET Identity implements `GetProfileDataAsync` by invoking the `IUserClaimsPrincipalFactory` implementation registered in the dependency injection container. The other method on `IProfileService` is `IsActiveAsync` which is used in various places in IdentityServer to validate that the user is (still) active. There is no built-in concept in ASP.NET Identity to inactive users, so our implementation is hard coded to return `true`. If you extend the ASP.NET Identity user with enabled/disabled functionality you should derive from our `ProfileService` and override *IsUserActiveAsync(TUser user)* to check your custom enabled/disabled flags. ## Template Alternatively, you can use the `isaspid` [template](/identityserver/overview/packaging#templates) to create a starter IdentityServer host project configured to use ASP.NET Identity. See the [Quickstart Documentation](/identityserver/quickstarts/5-aspnetid/) for a detailed walkthrough. diff --git a/src/content/docs/identityserver/configuration/dcr.md b/src/content/docs/identityserver/configuration/dcr.md index ecc3de178..739480f4f 100644 --- a/src/content/docs/identityserver/configuration/dcr.md +++ b/src/content/docs/identityserver/configuration/dcr.md @@ -73,7 +73,7 @@ needs an implementation of this interface. You can either use the built-in Entity Framework based implementation, or implement the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/stores/) for more details. If you wish to use the built-in implementation, install its NuGet -package and add it to DI. +package and add it to the ASP.NET Core service provider. ```bash title=Terminal dotnet add package Duende.IdentityServer.Configuration.EntityFramework @@ -128,7 +128,7 @@ needs an implementation of this interface. You can either use the built-in Entity Framework-based implementation, or implement the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/stores/client-store/) for more details. If you wish to use the built-in implementation, install its NuGet -package and add it to DI. +package and add it to the ASP.NET Core service provider. ```bash title=Terminal dotnet add package Duende.IdentityServer.Configuration.EntityFramework diff --git a/src/content/docs/identityserver/data/configuration.md b/src/content/docs/identityserver/data/configuration.md index 6e908f0a3..b90e39e8e 100644 --- a/src/content/docs/identityserver/data/configuration.md +++ b/src/content/docs/identityserver/data/configuration.md @@ -28,7 +28,7 @@ The stores used in Duende IdentityServer are: ## Registering Custom Stores -Custom implementations of the stores must be registered in the DI system. +Custom implementations of the stores must be registered in the ASP.NET Core service provider. There are [convenience methods](/identityserver/reference/di/#configuration-stores) for registering these. For example: @@ -49,7 +49,7 @@ same data. Duende IdentityServer provides [convenience methods](/identityserver/reference/di#caching-configuration-data) to enable caching data from the various stores. -The caching implementation relies upon an `ICache` service and must also be added to DI. +The caching implementation relies upon an `ICache` service and must also be added to the ASP.NET Core service provider. For example: ```cs diff --git a/src/content/docs/identityserver/data/index.md b/src/content/docs/identityserver/data/index.md index 828e5ccb3..45fd3afb6 100644 --- a/src/content/docs/identityserver/data/index.md +++ b/src/content/docs/identityserver/data/index.md @@ -15,7 +15,7 @@ Duende IdentityServer is backed by two kinds of data: * [Configuration Data](/identityserver/data/configuration/) * [Operational Data](/identityserver/data/operational/) -Data access is abstracted by store interfaces that are registered in the DI system. +Data access is abstracted by store interfaces that are registered in the ASP.NET Core service provider. These store interfaces allow IdentityServer to access the data it needs at runtime when processing requests. You can implement these interfaces yourself and thus can use any database you wish. If you prefer a relational database for this data, then we provide [EntityFramework Core](/identityserver/data/ef/) implementations. diff --git a/src/content/docs/identityserver/data/operational.md b/src/content/docs/identityserver/data/operational.md index 45d4386bf..c0f2a3886 100644 --- a/src/content/docs/identityserver/data/operational.md +++ b/src/content/docs/identityserver/data/operational.md @@ -38,7 +38,7 @@ The persistence for grants is abstracted behind two interfaces: ### Registering Custom Stores -Custom implementations of `IPersistedGrantStore`, and/or `IDeviceFlowStore` must be registered in the DI system. +Custom implementations of `IPersistedGrantStore`, and/or `IDeviceFlowStore` must be registered in the ASP.NET Core service provider. For example: ```cs @@ -77,7 +77,7 @@ The [ISigningKeyStore](/identityserver/reference/stores/signing-key-store/) is t ### Registering a custom signing key store -To register a custom signing key store in the DI container, there is a `AddSigningKeyStore` helper on the `IIdentityServerBuilder`. +To register a custom signing key store in the ASP.NET Core service provider, there is a `AddSigningKeyStore` helper on the `IIdentityServerBuilder`. For example: ```cs @@ -114,7 +114,7 @@ The methods on the [IServerSideSessionStore](/identityserver/reference/stores/se ### Registering a custom store -To register a custom server-side session store in the DI container, there is a `AddServerSideSessionStore` helper on the `IIdentityServerBuilder`. +To register a custom server-side session store in the ASP.NET Core service provider, there is a `AddServerSideSessionStore` helper on the `IIdentityServerBuilder`. It is still necessary to call `AddServerSideSessions` to enable the server-side session feature. For example: diff --git a/src/content/docs/identityserver/diagnostics/events.md b/src/content/docs/identityserver/diagnostics/events.md index 3350c9999..fd8792eeb 100644 --- a/src/content/docs/identityserver/diagnostics/events.md +++ b/src/content/docs/identityserver/diagnostics/events.md @@ -33,7 +33,7 @@ builder.Services.AddIdentityServer(options => }); ``` -To emit an event use the `IEventService` from the DI container and call the `RaiseAsync` method, e.g.: +To emit an event use the `IEventService` from the ASP.NET Core service provider and call the `RaiseAsync` method, e.g.: ```cs public async Task Login(LoginInputModel model) @@ -53,8 +53,8 @@ public async Task Login(LoginInputModel model) ### Custom sinks -Our default event sink will simply serialize the event class to JSON and forward it to the ASP.NET Core logging system. -If you want to connect to a custom event store, implement the `IEventSink` interface and register it with DI. +Our default event sink will serialize the event class to JSON and forward it to the ASP.NET Core logging system. +If you want to connect to a custom event store, implement the `IEventSink` interface and register it with the ASP.NET Core service provider. The following example uses [Seq](https://getseq.net) to emit events: diff --git a/src/content/docs/identityserver/fundamentals/claims.md b/src/content/docs/identityserver/fundamentals/claims.md index a84e3ac96..19bb28a7e 100644 --- a/src/content/docs/identityserver/fundamentals/claims.md +++ b/src/content/docs/identityserver/fundamentals/claims.md @@ -156,8 +156,8 @@ a [custom token request validator](/identityserver/tokens/dynamic-validation/). ## Claim Serialization -Claim values are serialized based on the `ClaimValueType` of the claim. Claims that don't specify a ClaimValueType are -simply serialized as strings. Claims that specify a ClaimValueType of `System.Security.Claims.ClaimValueTypes.Integer`, +Claim values are serialized based on the `ClaimValueType` of the claim. Claims that don't specify a `ClaimValueType` are +serialized as strings. Claims that specify a `ClaimValueType` of `System.Security.Claims.ClaimValueTypes.Integer`, `System.Security.Claims.ClaimValueTypes.Integer32`, `System.Security.Claims.ClaimValueTypes.Integer64`, `System.Security.Claims.ClaimValueTypes.Double`, or `System.Security.Claims.ClaimValueTypes.Boolean` are parsed as the corresponding type, while those that specify `IdentityServerConstants.ClaimValueTypes.Json` are serialized to JSON using diff --git a/src/content/docs/identityserver/fundamentals/hosting.md b/src/content/docs/identityserver/fundamentals/hosting.md index bcb915b69..d4da78aa2 100644 --- a/src/content/docs/identityserver/fundamentals/hosting.md +++ b/src/content/docs/identityserver/fundamentals/hosting.md @@ -19,7 +19,7 @@ putting your IdentityServer into a separate application. ## Dependency Injection System -You add the necessary services to the DI system by calling `AddIdentityServer` at application startup: +You add the necessary services to the ASP.NET Core service provider by calling `AddIdentityServer` at application startup: ```cs //Program.cs @@ -29,7 +29,7 @@ var idsvrBuilder = builder.Services.AddIdentityServer(options => { ... }); Many of the fundamental configuration settings can be set on the options. See the `[IdentityServerOptions](/identityserver/reference/options)` reference for more details. -The builder object has a number of extension methods to add additional services to DI. +The builder object has a number of extension methods to add additional services to the ASP.NET Core service provider. You can see the full list in the [reference](/identityserver/reference/di) section, but very commonly you start by adding the configuration stores for clients and resources, e.g.: diff --git a/src/content/docs/identityserver/fundamentals/key-management.md b/src/content/docs/identityserver/fundamentals/key-management.md index 361bf230a..6b93126c3 100644 --- a/src/content/docs/identityserver/fundamentals/key-management.md +++ b/src/content/docs/identityserver/fundamentals/key-management.md @@ -366,7 +366,7 @@ clients and APIs have updated their caches. Next, start signing tokens with the new key, but continue to publish the public key of the old key so that tokens that were signed with that key can continue to -be validated. The IdentityServer configuration change needed is simply to swap +be validated. The IdentityServer configuration change needed is to swap the signing credential and validation key. ```cs diff --git a/src/content/docs/identityserver/fundamentals/resources/isolation.md b/src/content/docs/identityserver/fundamentals/resources/isolation.md index 521e29ade..f0008d8bc 100644 --- a/src/content/docs/identityserver/fundamentals/resources/isolation.md +++ b/src/content/docs/identityserver/fundamentals/resources/isolation.md @@ -44,7 +44,7 @@ var resources = new[] }; ``` -If the client would simply request a token for the `read` scope, the resulting access token would contain the audience of both the invoice and the products API and thus be accepted at both APIs. +If the client would request a token for the `read` scope, the resulting access token would contain the audience of both the invoice and the products API and thus be accepted at both APIs. ### Machine to Machine Scenarios If the client in addition passes the `resource` parameter specifying the name of the resource where it wants to use the access token, the token engine can `down-scope` the resulting access token to the single resource, e.g.: diff --git a/src/content/docs/identityserver/reference/dcr/processing.md b/src/content/docs/identityserver/reference/dcr/processing.md index 4eb72dfbc..db9d7d12d 100644 --- a/src/content/docs/identityserver/reference/dcr/processing.md +++ b/src/content/docs/identityserver/reference/dcr/processing.md @@ -60,8 +60,8 @@ have its properties set, the DCR request, and other contextual information. The ## Secret Generation The `AddClientSecret` method is responsible for adding the client's secret and -plaintext of that secret to the context's `Items` dictionary for later use. If you want to customize secret generation -more simply, you can override the GenerateSecret method, which only needs to return a tuple containing the secret and +plaintext of that secret to the context's `Items` dictionary for later use. If you want to customize secret generation, +you can override the GenerateSecret method, which only needs to return a tuple containing the secret and its plaintext. | name | description | diff --git a/src/content/docs/identityserver/reference/di.md b/src/content/docs/identityserver/reference/di.md index 8864d6436..26a1c39cd 100644 --- a/src/content/docs/identityserver/reference/di.md +++ b/src/content/docs/identityserver/reference/di.md @@ -12,7 +12,7 @@ redirect_from: --- `AddIdentityServer` return a builder object that provides many extension methods to add IdentityServer specific services -to DI. Here's a list grouped by feature areas. +to the ASP.NET Core service provider. Here's a list grouped by feature areas. ```cs // Program.cs @@ -72,7 +72,7 @@ enable [caching for configuration data](/identityserver/data/configuration#cachi * **`AddInMemoryCaching`** - To use any of the caches described below, an implementation of `ICache` must be registered in DI. + To use any of the caches described below, an implementation of `ICache` must be registered in the ASP.NET Core service provider. This API registers a default in-memory implementation of `ICache` that's based on ASP.NET Core's `MemoryCache`. * **`AddClientStoreCache`** diff --git a/src/content/docs/identityserver/reference/response-handling/token_response_generator.md b/src/content/docs/identityserver/reference/response-handling/token_response_generator.md index c0824224e..53e7e81f3 100644 --- a/src/content/docs/identityserver/reference/response-handling/token_response_generator.md +++ b/src/content/docs/identityserver/reference/response-handling/token_response_generator.md @@ -15,7 +15,7 @@ the token endpoint. A response in this context refers to an object model that de serialized and transmitted in the HTTP response. The default implementation is the `TokenResponseGenerator` class. You can customize the behavior of the token endpoint -by providing your own implementation of the `ITokenResponseGenerator` to the DI system. +by providing your own implementation of the `ITokenResponseGenerator` to the ASP.NET Core service provider. To create a customized implementation of `ITokenResponseGenerator`, we recommend that you create a class that derives from the default implementation. Your custom implementation should override the appropriate virtual methods of the diff --git a/src/content/docs/identityserver/reference/services/ciba-user-notification.md b/src/content/docs/identityserver/reference/services/ciba-user-notification.md index a57ea80d1..861ca5d7e 100644 --- a/src/content/docs/identityserver/reference/services/ciba-user-notification.md +++ b/src/content/docs/identityserver/reference/services/ciba-user-notification.md @@ -13,7 +13,7 @@ redirect_from: The `IBackchannelAuthenticationUserNotificationService` interface is used to contact users when a [CIBA](/identityserver/ui/ciba) login request has been made. -To use CIBA, you are expected to implement this interface and register it in the DI system. +To use CIBA, you are expected to implement this interface and register it in the ASP.NET Core service provider. ## IBackchannelAuthenticationUserNotificationService APIs diff --git a/src/content/docs/identityserver/reference/validators/ciba-user-validator.md b/src/content/docs/identityserver/reference/validators/ciba-user-validator.md index b60bc06d0..ebe9d1067 100644 --- a/src/content/docs/identityserver/reference/validators/ciba-user-validator.md +++ b/src/content/docs/identityserver/reference/validators/ciba-user-validator.md @@ -13,7 +13,7 @@ redirect_from: The `IBackchannelAuthenticationUserValidator` interface is used to validate request hints and identify the user for whom the [CIBA](/identityserver/ui/ciba) request is intended. -To use CIBA, you are expected to implement this interface and register it in the DI system. +To use CIBA, you are expected to implement this interface and register it in the ASP.NET Core service provider. ## IBackchannelAuthenticationUserValidator APIs diff --git a/src/content/docs/identityserver/tokens/client-authentication.md b/src/content/docs/identityserver/tokens/client-authentication.md index 40e0dbb0e..1b8104e08 100644 --- a/src/content/docs/identityserver/tokens/client-authentication.md +++ b/src/content/docs/identityserver/tokens/client-authentication.md @@ -59,7 +59,7 @@ client.ClientSecrets = new[] { primary, secondary }; ### Secret Parsing During request processing, the secret must be somehow extracted from the incoming request. The various specs describe a couple of options, e.g. as part of the authorization header or the body payload. -It is the job of implementations of the [ISecretParser](/identityserver/reference/models/secrets#duendeidentityservervalidationisecretparser) interface to accomplish this. You can add secret parsers by calling the `AddSecretParser()` DI extension method. +It is the job of implementations of the [ISecretParser](/identityserver/reference/models/secrets#duendeidentityservervalidationisecretparser) interface to accomplish this. You can add secret parsers by calling the `AddSecretParser()` service provider extension method. The following secret parsers are part of Duende IdentityServer: @@ -76,18 +76,18 @@ The following secret parsers are part of Duende IdentityServer: * **`Duende.IdentityServer.Validation.JwtBearerClientAssertionSecretParser`** Parses a JWT on the `client_assertion` body field. - Can be enabled by calling the `AddJwtBearerClientAuthentication` DI extension method. + Can be enabled by calling the `AddJwtBearerClientAuthentication` service provider extension method. * **`Duende.IdentityServer.Validation.MutualTlsSecretParser`** Parses the `client_id` body field and TLS client certificate. - Can be enabled by calling the `AddMutualTlsSecretValidators` DI extension method. + Can be enabled by calling the `AddMutualTlsSecretValidators` service provider extension method. ### Secret Validation It is the job of implementations of the [ISecretValidator](/identityserver/reference/models/secrets#duendeidentityservermodelparsedsecret) interface to validate the extracted credentials. -You can add secret validators by calling the `AddSecretValidator()` DI extension method. +You can add secret validators by calling the `AddSecretValidator()` service provider extension method. The following secret validators are part of Duende IdentityServer: @@ -103,17 +103,17 @@ The following secret validators are part of Duende IdentityServer: * **`Duende.IdentityServer.Validation.PrivateKeyJwtSecretValidator`** Validates JWTs that are signed with either X.509 certificates or keys wrapped in a JWK. - Can be enabled by calling the `AddJwtBearerClientAuthentication` DI extension method. + Can be enabled by calling the `AddJwtBearerClientAuthentication` service provider extension method. * **`Duende.IdentityServer.Validation.X509ThumbprintSecretValidator`** Validates X.509 client certificates based on a thumbprint. - Can be enabled by calling the `AddMutualTlsSecretValidators` DI extension method. + Can be enabled by calling the `AddMutualTlsSecretValidators` service provider extension method. * **`Duende.IdentityServer.Validation.X509NameSecretValidator`** Validates X.509 client certificates based on a common name. - Can be enabled by calling the `AddMutualTlsSecretValidators` DI extension method. + Can be enabled by calling the `AddMutualTlsSecretValidators` service provider extension method. ## Shared Secrets @@ -422,8 +422,8 @@ var idsvrBuilder = builder.Services.AddIdentityServer(options => }) ``` -Use the [DI extensions methods](/identityserver/reference/di) to add the services to DI which contain a default -implementation to do that either thumbprint or common-name based: +Use the [ASP.NET Core service provider extensions methods](/identityserver/reference/di) to add the services to the +ASP.NET Core service provider. A default implementation is available to do that either thumbprint or common-name based: ```cs idsvrBuilder.AddMutualTlsSecretValidators(); diff --git a/src/content/docs/identityserver/tokens/cors.md b/src/content/docs/identityserver/tokens/cors.md index 7e53c6dc1..d832672de 100644 --- a/src/content/docs/identityserver/tokens/cors.md +++ b/src/content/docs/identityserver/tokens/cors.md @@ -20,7 +20,7 @@ configured. One approach to configuring CORS is to use the `AllowedCorsOrigins` collection on the [client configuration](/identityserver/reference/models/client#authentication--session-management). -Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these +Add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins. :::note @@ -40,16 +40,15 @@ CORS policy. The single method to implement is: *Task IsOriginAllowedAsync(string origin)*. Return `true` if the `origin` is allowed, `false` otherwise. -Once implemented, simply register the implementation in DI and IdentityServer will then use your custom implementation. +Once implemented, register the implementation in the ASP.NET Core service provider and IdentityServer will then use your custom implementation. ### DefaultCorsPolicyService -If you simply wish to hard-code a set of allowed origins, then there is a pre-built `ICorsPolicyService` implementation +If you wish to hard-code a set of allowed origins, then there is a pre-built `ICorsPolicyService` implementation you can use called `DefaultCorsPolicyService`. This would be configured as a singleton in DI, and hard-coded with its `AllowedOrigins` collection, or setting the flag -`AllowAll` -to `true` to allow all origins. +`AllowAll` to `true` to allow all origins. For example, in `ConfigureServices`: @@ -88,8 +87,8 @@ too should continue to work normally. The one scenario where there might be a conflict between your use of the ASP.NET Core CORS services and IdentityServer is if you decide to create a custom `ICorsPolicyProvider`. Given the design of the ASP.NET Core's CORS services and middleware, IdentityServer implements its own custom -`ICorsPolicyProvider` and registers it in the DI system. +`ICorsPolicyProvider` and registers it in the ASP.NET Core service provider. Fortunately, the IdentityServer implementation is designed to use the decorator pattern to wrap any existing -`ICorsPolicyProvider` that is already registered in DI. -What this means is that you can also implement the `ICorsPolicyProvider`, but it simply needs to be registered prior to -IdentityServer in DI (e.g. in `ConfigureServices`). +`ICorsPolicyProvider` that is already registered in the service provider. +What this means is that you can also implement the `ICorsPolicyProvider`, but it needs to be registered prior to +IdentityServer in the service provider (e.g. in `ConfigureServices`). diff --git a/src/content/docs/identityserver/tokens/pop.md b/src/content/docs/identityserver/tokens/pop.md index 780a9c150..55a3b9f8e 100644 --- a/src/content/docs/identityserver/tokens/pop.md +++ b/src/content/docs/identityserver/tokens/pop.md @@ -201,7 +201,7 @@ new Client The easiest approach for supporting DPoP in your client is to use the DPoP support in the `Duende.AccessTokenManagement` library ([docs available here](https://github.com/DuendeSoftware/Duende.AccessTokenManagement/wiki/DPoP)). It provides DPoP client support for both client credentials and code flow style clients. -DPoP is enabled by simply assigning the `DPoPJsonWebKey` on the client configuration. +DPoP is enabled by assigning the `DPoPJsonWebKey` on the client configuration. For example, here's how to configure a client credentials client: diff --git a/src/content/docs/identityserver/tokens/refresh.md b/src/content/docs/identityserver/tokens/refresh.md index 613c9311d..519821b6b 100644 --- a/src/content/docs/identityserver/tokens/refresh.md +++ b/src/content/docs/identityserver/tokens/refresh.md @@ -148,7 +148,7 @@ the amount of time that must elapse before tokens marked as consumed will be del Token Service to allow for consumed tokens to be used for some period of time, then we recommend configuring the `ConsumedTokenCleanupDelay` to the same time period. -This customization must be registered in the DI system as an implementation of the `IRefreshTokenService`: +This customization must be registered in the ASP.NET Core service provider as an implementation of the `IRefreshTokenService`: ```csharp builder.Services.TryAddTransient(); diff --git a/src/content/docs/identityserver/ui/ciba.md b/src/content/docs/identityserver/ui/ciba.md index 7392ee89f..209b41fb9 100644 --- a/src/content/docs/identityserver/ui/ciba.md +++ b/src/content/docs/identityserver/ui/ciba.md @@ -36,12 +36,12 @@ Below is a diagram that shows the high level steps involved with the CIBA workfl * **Step 1**: IdentityServer exposes a [backchannel authentication request endpoint](/identityserver/reference/endpoints/ciba) that the client uses to initiate the CIBA workflow. * **Step 2**: Once client authentication and basic request parameter validation is performed, the user for which the request is being made must be identified. -This is done by using the [IBackchannelAuthenticationUserValidator](/identityserver/reference/validators/ciba-user-validator/) service in DI, **which you are required to implement and register in the DI system**. +This is done by using the [IBackchannelAuthenticationUserValidator](/identityserver/reference/validators/ciba-user-validator/) service in DI, **which you are required to implement and register in the ASP.NET Core service provider**. The `ValidateRequestAsync` method will validate the request parameters and return a result which will contain the user's `sub` (subject identifier) claim. * **Step 3**: Once a user has successfully been identified, then a record representing the pending login request is created in the [Backchannel Authentication Request Store](/identityserver/reference/stores/backchannel-auth-request-store/). -* **Step 4**: Next, the user needs to be notified of the login request. This is done by using the [IBackchannelAuthenticationUserNotificationService](/identityserver/reference/services/ciba-user-notification/) service in DI, **which you are required to implement and register in the DI system**. +* **Step 4**: Next, the user needs to be notified of the login request. This is done by using the [IBackchannelAuthenticationUserNotificationService](/identityserver/reference/services/ciba-user-notification/) service in DI, **which you are required to implement and register in the ASP.NET Core service provider**. The `SendLoginRequestAsync` method should contact the user with whatever mechanism is appropriate (e.g. email, text message, push notification, etc.), and presumably provide the user with instructions (perhaps via a link, but other approaches are conceivable) to start the login and consent process. This method is passed a [BackchannelUserLoginRequest](/identityserver/reference/models/ciba-login-request/) which will contain all the contextual information needed to send to the user (the `InternalId` being the identifier for this login request which is needed when completing the request -- see below). diff --git a/src/content/docs/identityserver/ui/consent.md b/src/content/docs/identityserver/ui/consent.md index bd90439c1..c2144757c 100644 --- a/src/content/docs/identityserver/ui/consent.md +++ b/src/content/docs/identityserver/ui/consent.md @@ -68,7 +68,7 @@ authorization endpoint. This temporary persistence is different from the persistence used for the "remember my consent" feature (and it is the authorization endpoint which persists the "remember my consent" for the user). If you wish to use some other persistence between the consent page and the authorization redirect, then you can -implement `IMessageStore` and register the implementation in DI. +implement `IMessageStore` and register the implementation with the service provider. ## Returning The User To The Authorization Endpoint diff --git a/src/content/docs/identityserver/ui/error.md b/src/content/docs/identityserver/ui/error.md index 49491dcb5..f19bbc036 100644 --- a/src/content/docs/identityserver/ui/error.md +++ b/src/content/docs/identityserver/ui/error.md @@ -41,7 +41,7 @@ builder.Services.AddIdentityServer(opt => { }) ``` -By default, the `ErrorId` is simply the string "errorId". +By default, the `ErrorId` is the string "errorId". The [interaction service](/identityserver/reference/services/interaction-service/#iidentityserverinteractionservice-apis) provides a `GetErrorContextAsync` API that will load error details for an `ErrorId`. diff --git a/src/content/docs/identityserver/ui/login/dynamicproviders.md b/src/content/docs/identityserver/ui/login/dynamicproviders.md index 301d979f3..f8d7eb4c9 100644 --- a/src/content/docs/identityserver/ui/login/dynamicproviders.md +++ b/src/content/docs/identityserver/ui/login/dynamicproviders.md @@ -17,7 +17,7 @@ of Duende IdentityServer, enables providers to be configured dynamically from a Normally authentication handlers for external providers are added into your IdentityServer using `AddAuthentication()` and `AddOpenIdConnect()`. This is fine for a handful of schemes, but the authentication handler architecture in ASP.NET -Core was not designed for dozens or more statically registered in the DI system. At some point you will incur a +Core was not designed for dozens or more statically registered in the ASP.NET Core service provider. At some point you will incur a performance penalty for having too many. Also, as you need to add or change this configuration you will need to re-compile and re-run your startup code for those changes to take effect. @@ -104,7 +104,7 @@ properties and how they are mapped to the options. #### Customizing OpenIdConnectOptions -If it is needed to further customize the `OpenIdConnectOptions`, you can register in the DI system an instance of +If it is needed to further customize the `OpenIdConnectOptions`, you can register in the ASP.NET Core service provider an instance of `IConfigureNamedOptions`. For example: ```cs @@ -124,7 +124,7 @@ public class CustomConfig : IConfigureNamedOptions } ``` -And to register this in the DI system: +And to register this in the ASP.NET Core service provider: ```cs builder.Services.ConfigureOptions(); @@ -156,7 +156,7 @@ class CustomOidcConfigureOptions : ConfigureAuthenticationOptions