From c3a5b12fba0509d41b0a28405e0929ddb6f76c06 Mon Sep 17 00:00:00 2001 From: Joe DeCock Date: Tue, 3 Oct 2023 10:55:05 -0500 Subject: [PATCH] Remove csharp language from code blocks In the latest version of hugo, there is a bug where csharp code blocks indentation is broken, but if you allow hugo to infer the language, indentation works (and the inferred syntax highlighting seems correct too, somehow). --- .../v6/docs/content/apis/add_apis.md | 22 +++++++-------- .../content/apis/aspnetcore/authorization.md | 12 ++++---- .../content/apis/aspnetcore/confirmation.md | 8 +++--- .../v6/docs/content/apis/aspnetcore/jwt.md | 4 +-- .../docs/content/apis/aspnetcore/reference.md | 6 ++-- .../v6/docs/content/bff/apis/local.md | 18 ++++++------ .../v6/docs/content/bff/apis/remote.md | 4 +-- .../v6/docs/content/bff/apis/yarp.md | 14 +++++----- .../bff/extensibility/http_forwarder.md | 8 +++--- .../bff/extensibility/management/_index.md | 4 +-- .../management/back-channel-logout.md | 6 ++-- .../extensibility/management/diagnostics.md | 2 +- .../bff/extensibility/management/login.md | 2 +- .../bff/extensibility/management/logout.md | 2 +- .../management/silent-login-callback.md | 2 +- .../extensibility/management/silent-login.md | 2 +- .../bff/extensibility/management/user.md | 4 +-- .../content/bff/extensibility/sessions.md | 2 +- .../docs/content/bff/extensibility/tokens.md | 8 +++--- IdentityServer/v6/docs/content/bff/options.md | 2 +- .../v6/docs/content/bff/session/handlers.md | 6 ++-- .../content/bff/session/management/_index.md | 4 +-- .../content/bff/session/management/login.md | 2 +- .../bff/session/server_side_sessions.md | 8 +++--- IdentityServer/v6/docs/content/bff/tokens.md | 14 +++++----- .../content/configuration/dcr/installation.md | 12 ++++---- .../configuration/dcr/reference/models.md | 12 ++++---- .../configuration/dcr/reference/options.md | 4 +-- .../configuration/dcr/reference/processing.md | 2 +- .../configuration/dcr/reference/response.md | 2 +- .../configuration/dcr/reference/store.md | 2 +- .../configuration/dcr/reference/validation.md | 4 +-- .../v6/docs/content/data/configuration.md | 6 ++-- IdentityServer/v6/docs/content/data/ef.md | 10 +++---- .../docs/content/data/operational/grants.md | 2 +- .../v6/docs/content/data/operational/keys.md | 2 +- .../docs/content/data/operational/sessions.md | 6 ++-- .../content/deployment/data_protection.md | 2 +- .../v6/docs/content/diagnostics/events.md | 8 +++--- .../v6/docs/content/diagnostics/logging.md | 2 +- .../v6/docs/content/diagnostics/otel.md | 2 +- .../v6/docs/content/fundamentals/claims.md | 6 ++-- .../v6/docs/content/fundamentals/clients.md | 6 ++-- .../v6/docs/content/fundamentals/hosting.md | 6 ++-- .../keys/automatic_key_management.md | 6 ++-- .../content/fundamentals/keys/migration.md | 6 ++-- .../keys/static_key_management.md | 10 +++---- .../docs/content/fundamentals/license_key.md | 2 +- .../fundamentals/resources/api_resources.md | 8 +++--- .../fundamentals/resources/api_scopes.md | 8 +++--- .../fundamentals/resources/identity.md | 8 +++--- .../fundamentals/resources/isolation.md | 4 +-- .../v6/docs/content/overview/big_picture.md | 2 +- .../quickstarts/1_client_credentials.md | 23 +++++++-------- .../docs/content/quickstarts/2_interactive.md | 28 +++++++++---------- .../docs/content/quickstarts/3_api_access.md | 6 ++-- .../v6/docs/content/quickstarts/4_ef.md | 8 +++--- .../v6/docs/content/quickstarts/5_aspnetid.md | 18 ++++++------ .../v6/docs/content/quickstarts/7_blazor.md | 20 ++++++------- .../quickstarts/js_clients/js_with_backend.md | 10 +++---- .../js_clients/js_without_backend.md | 8 +++--- .../v6/docs/content/reference/di.md | 2 +- .../reference/efoptions/configuration.md | 2 +- .../reference/efoptions/operational.md | 2 +- .../content/reference/endpoints/authorize.md | 2 +- .../docs/content/reference/endpoints/ciba.md | 4 +-- .../endpoints/device_authorization.md | 2 +- .../content/reference/endpoints/discovery.md | 2 +- .../reference/endpoints/end_session.md | 2 +- .../reference/endpoints/introspection.md | 2 +- .../content/reference/endpoints/revocation.md | 2 +- .../docs/content/reference/endpoints/token.md | 2 +- .../content/reference/endpoints/userinfo.md | 2 +- .../content/reference/models/api_resource.md | 2 +- .../content/reference/models/api_scope.md | 2 +- .../docs/content/reference/models/client.md | 2 +- .../models/grant_validation_result.md | 4 +-- .../reference/models/identity_resource.md | 2 +- .../docs/content/reference/models/secrets.md | 6 ++-- .../v6/docs/content/reference/options.md | 8 +++--- .../services/persisted_grant_service.md | 4 +-- .../reference/services/profile_service.md | 2 +- .../services/refresh_token_service.md | 2 +- .../services/session_management_service.md | 6 ++-- .../stores/backchannel_auth_request_store.md | 4 +-- .../content/reference/stores/client_store.md | 2 +- .../reference/stores/cors_policy_service.md | 2 +- .../reference/stores/device_flow_store.md | 4 +-- .../content/reference/stores/idp_store.md | 2 +- .../reference/stores/persisted_grant_store.md | 4 +-- .../reference/stores/resource_store.md | 2 +- .../reference/stores/server_side_sessions.md | 10 +++---- .../reference/stores/signing_key_store.md | 4 +-- .../custom_authorize_request_validator.md | 2 +- .../custom_token_request_validator.md | 2 +- .../validators/extension_grant_validator.md | 4 +-- .../docs/content/tokens/authentication/jwt.md | 8 +++--- .../content/tokens/authentication/mtls.md | 8 +++--- .../content/tokens/authentication/overview.md | 4 +-- .../tokens/authentication/shared_secret.md | 6 ++-- IdentityServer/v6/docs/content/tokens/cors.md | 2 +- .../docs/content/tokens/dynamic_validation.md | 4 +-- .../tokens/extension_grants/token_exchange.md | 12 ++++---- .../v6/docs/content/tokens/internal.md | 2 +- IdentityServer/v6/docs/content/tokens/jar.md | 4 +-- .../v6/docs/content/tokens/password_grant.md | 4 +-- .../v6/docs/content/tokens/pop/dpop.md | 8 +++--- .../v6/docs/content/tokens/pop/mtls.md | 6 ++-- .../v6/docs/content/tokens/reference.md | 4 +-- .../v6/docs/content/tokens/refresh.md | 2 +- .../v6/docs/content/tokens/requesting.md | 10 +++---- IdentityServer/v6/docs/content/ui/consent.md | 2 +- IdentityServer/v6/docs/content/ui/custom.md | 2 +- IdentityServer/v6/docs/content/ui/error.md | 4 +-- .../v6/docs/content/ui/login/_index.md | 6 ++-- .../docs/content/ui/login/dynamicproviders.md | 12 ++++---- .../v6/docs/content/ui/login/external.md | 18 ++++++------ .../v6/docs/content/ui/login/local.md | 2 +- .../v6/docs/content/ui/login/session.md | 10 +++---- .../v6/docs/content/ui/login/windows.md | 4 +-- .../v6/docs/content/ui/logout/_index.md | 6 ++-- .../v6/docs/content/ui/logout/external.md | 4 +-- .../docs/content/ui/logout/session_cleanup.md | 6 ++-- .../content/ui/server_side_sessions/_index.md | 4 +-- .../session_expiration.md | 2 +- .../session_management.md | 8 +++--- .../v6/docs/outtakes/application_types.md | 6 ++-- IdentityServer/v6/docs/outtakes/mtls.md | 24 ++++++++-------- 128 files changed, 375 insertions(+), 374 deletions(-) diff --git a/IdentityServer/v6/docs/content/apis/add_apis.md b/IdentityServer/v6/docs/content/apis/add_apis.md index 3cd7422c..551e7710 100644 --- a/IdentityServer/v6/docs/content/apis/add_apis.md +++ b/IdentityServer/v6/docs/content/apis/add_apis.md @@ -15,7 +15,7 @@ You could achieve the same by using either Microsoft's *JwtBearer* handler. But Start by registering your API as an *ApiScope*, (or resource) e.g.: -```cs +``` var scopes = new List { // local API @@ -25,7 +25,7 @@ var scopes = new List ..and give your clients access to this API, e.g.: -```cs +``` new Client { // rest omitted @@ -39,21 +39,21 @@ The value of *IdentityServerConstants.LocalApi.ScopeName* is *IdentityServerApi* To enable token validation for local APIs, add the following to your IdentityServer startup: -```cs +``` services.AddLocalApiAuthentication(); ``` To protect an API controller, decorate it with an *Authorize* attribute using the *LocalApi.PolicyName* policy: -```cs +``` [Route("localApi")] [Authorize(LocalApi.PolicyName)] public class LocalApiController : ControllerBase { - public IActionResult Get() - { - // omitted - } + public IActionResult Get() + { + // omitted + } } ``` @@ -62,7 +62,7 @@ Authorized clients can then request a token for the *IdentityServerApi* scope an ## Discovery You can also add your endpoints to the discovery document if you want, e.g like this:: -```cs +``` services.AddIdentityServer(options => { options.Discovery.CustomEntries.Add("local_api", "~/localapi"); @@ -83,7 +83,7 @@ This covers the most common scenarios. You can customize this behavior in the fo * Do your own scope validation/authorization in your controllers using custom policies or code, e.g.: -```cs +``` services.AddAuthorization(options => { options.AddPolicy(IdentityServerConstants.LocalApi.PolicyName, policy => @@ -99,7 +99,7 @@ This covers the most common scenarios. You can customize this behavior in the fo You can provide a callback to transform the claims of the incoming token after validation. Either use the helper method, e.g.: -```cs +``` services.AddLocalApiAuthentication(principal => { principal.Identities.First().AddClaim(new Claim("additional_claim", "additional_value")); diff --git a/IdentityServer/v6/docs/content/apis/aspnetcore/authorization.md b/IdentityServer/v6/docs/content/apis/aspnetcore/authorization.md index 592eb1ad..149a6069 100644 --- a/IdentityServer/v6/docs/content/apis/aspnetcore/authorization.md +++ b/IdentityServer/v6/docs/content/apis/aspnetcore/authorization.md @@ -8,7 +8,7 @@ The access token will include additional claims that can be used for authorizati In ASP.NET core, the contents of the JWT payload get transformed into claims and packaged up in a *ClaimsPrincipal*. So you can always write custom validation or authorization logic in C#: -```cs +``` public IActionResult Get() { var isAllowed = User.HasClaim("scope", "read"); @@ -21,7 +21,7 @@ For better encapsulation and re-use, consider using the ASP.NET Core [authorizat With this approach, you would first turn the claim requirement(s) into a named policy: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(options => @@ -34,7 +34,7 @@ public void ConfigureServices(IServiceCollection services) ..and then enforce it, e.g. using the routing table: -```cs +``` app.UseEndpoints(endpoints => { endpoints.MapControllers().RequireAuthorization("read_access"); @@ -43,7 +43,7 @@ public void ConfigureServices(IServiceCollection services) ...or imperatively inside the controller: -```cs +``` public class DataController : ControllerBase { IAuthorizationService _authz; @@ -64,7 +64,7 @@ public class DataController : ControllerBase ... or declaratively: -```cs +``` public class DataController : ControllerBase { [Authorize("read_access")] @@ -82,7 +82,7 @@ Historically, Duende IdentityServer emitted the *scope* claims as an array in th The newer *JWT Profile for OAuth* [spec]({{< ref "/overview/specs" >}}) mandates that the scope claim is a single space delimited string. You can switch the format by setting the *EmitScopesAsSpaceDelimitedStringInJwt* on the [options]({{< ref "/reference/options" >}}). But this means that the code consuming access tokens might need to be adjusted. The following code can do a conversion to the *multiple claims* format that .NET prefers: -```cs +``` namespace IdentityModel.AspNetCore.AccessTokenValidation { /// diff --git a/IdentityServer/v6/docs/content/apis/aspnetcore/confirmation.md b/IdentityServer/v6/docs/content/apis/aspnetcore/confirmation.md index a106211c..ab035d86 100644 --- a/IdentityServer/v6/docs/content/apis/aspnetcore/confirmation.md +++ b/IdentityServer/v6/docs/content/apis/aspnetcore/confirmation.md @@ -12,7 +12,7 @@ If you are using a [mutual TLS connection]({{< ref "/tokens/pop/mtls" >}}) to es You can do so with custom middleware like this: -```cs +``` public void Configure(IApplicationBuilder app) { // rest omitted @@ -31,7 +31,7 @@ public void Configure(IApplicationBuilder app) Here, *UseConfirmationValidation* is an extension method that registers the middleware that performs the necessary validation: -```cs +``` public static class ConfirmationValidationExtensions { public static IApplicationBuilder UseConfirmationValidation(this IApplicationBuilder app, ConfirmationValidationMiddlewareOptions options = default) @@ -43,7 +43,7 @@ public static class ConfirmationValidationExtensions And this is the actual middleware that validates the *cnf* claim: -```cs +``` // this middleware validates the cnf claim (if present) against the thumbprint of the X.509 client certificate for the current client public class ConfirmationValidationMiddleware { @@ -117,7 +117,7 @@ DPoP proof token processing involves requiring the DPoP scheme on the authorizat Given that there are no off-the-shelf libraries that implement this, we have developed a full-featured sample implementation. With this sample the configuration necessary in your startup can be as simple as this: -```cs +``` public void ConfigureServices(IServiceCollection services) { diff --git a/IdentityServer/v6/docs/content/apis/aspnetcore/jwt.md b/IdentityServer/v6/docs/content/apis/aspnetcore/jwt.md index e2eb6b62..ce5f6aa9 100644 --- a/IdentityServer/v6/docs/content/apis/aspnetcore/jwt.md +++ b/IdentityServer/v6/docs/content/apis/aspnetcore/jwt.md @@ -15,7 +15,7 @@ First you need to add a reference to the authentication handler in your API proj If all you care about is making sure that an access token comes from your trusted IdentityServer, the following snippet shows the typical JWT validation configuration for ASP.NET Core: -```cs +``` public class Startup { public void ConfigureServices(IServiceCollection services) @@ -65,7 +65,7 @@ If you designed your APIs around the concept of [API resources]({{< ref "/fundam If you want to express in your API, that only access tokens for the *api1* audience (aka API resource name) are accepted, change the above code snippet to: -```cs +``` public class Startup { public void ConfigureServices(IServiceCollection services) diff --git a/IdentityServer/v6/docs/content/apis/aspnetcore/reference.md b/IdentityServer/v6/docs/content/apis/aspnetcore/reference.md index 4aba48c3..da7c8fb1 100644 --- a/IdentityServer/v6/docs/content/apis/aspnetcore/reference.md +++ b/IdentityServer/v6/docs/content/apis/aspnetcore/reference.md @@ -6,7 +6,7 @@ weight: 20 If you are using [reference tokens]({{< ref "/tokens/reference" >}}), you need an authentication handler that implements the back-channel validation via the [OAuth 2.0 token introspection](https://tools.ietf.org/html/rfc7662) protocol, e.g. [this](https://github.com/IdentityModel/IdentityModel.AspNetCore.OAuth2Introspection) one:. -```cs +``` services.AddAuthentication("token") .AddOAuth2Introspection("token", options => { @@ -21,7 +21,7 @@ services.AddAuthentication("token") ## Supporting both JWTs and reference tokens It is not uncommon to use the same API with both JWTs and reference tokens. In this case you setup two authentication handlers, make one the default handler and provide some forwarding logic, e.g.: -```cs +``` services.AddAuthentication("token") // JWT tokens @@ -48,7 +48,7 @@ services.AddAuthentication("token") The logic of the forward selector looks like this: -```cs +``` /// /// Provides a forwarding func for JWT vs reference tokens (based on existence of dot in token) /// diff --git a/IdentityServer/v6/docs/content/bff/apis/local.md b/IdentityServer/v6/docs/content/bff/apis/local.md index 04d13f76..6e36cbb9 100644 --- a/IdentityServer/v6/docs/content/bff/apis/local.md +++ b/IdentityServer/v6/docs/content/bff/apis/local.md @@ -21,7 +21,7 @@ Alternatively, you can make the data available as a service and make HTTP reques Your local endpoints can leverage services like the HTTP client factory and Duende.BFF [token management]({{< ref "/bff/tokens" >}}) to make the outgoing calls. The following is a simplified example showing how local endpoints can obtain managed access tokens and use them to make requests to remote APIs. -```cs +``` [Route("myApi")] public class MyApiController : ControllerBase { @@ -82,7 +82,7 @@ Duende.BFF can automate both the pre-processing step of requiring the custom ant #### Add Middleware Add the BFF middleware to the pipeline by calling *UseBFF*. Note that the middleware must be placed before the authorization middleware, but after routing. -```csharp +``` public void Configure(IApplicationBuilder app) { // rest omitted @@ -102,7 +102,7 @@ public void Configure(IApplicationBuilder app) Endpoints that require the pre and post processing described above must be decorated with a call to *AsBffApiEndpoint()*. For minimal API endpoints, you can apply BFF pre- and post-processing when they are mapped. -```csharp +``` endpoints.MapPost("/foo", context => { ... }) .RequireAuthorization() // no anonymous access .AsBffApiEndpoint(); // BFF pre/post processing @@ -110,14 +110,14 @@ endpoints.MapPost("/foo", context => { ... }) For MVC controllers, you can similarly apply BFF pre- and post-processing to controller actions when they are mapped. -```csharp +``` endpoints.MapControllers() .RequireAuthorization() // no anonymous access .AsBffApiEndpoint(); // BFF pre/post processing ``` Alternatively, you can apply the *[BffApi]* attribute directly to the controller or action. -```csharp +``` [Route("myApi")] [BffApi] public class MyApiController : ControllerBase @@ -132,7 +132,7 @@ However, if you are defending against CSRF attacks with some other mechanism, yo For *version 1.x*, set the *requireAntiForgeryCheck* parameter to *false* when adding the endpoint. For example: -```csharp +``` app.UseEndpoints(endpoints => { // MVC controllers @@ -153,7 +153,7 @@ app.UseEndpoints(endpoints => On MVC controllers and actions you can set the *RequireAntiForgeryCheck* as a flag in the *BffApiAttribute*, like this: -```csharp +``` [Route("sample")] // WARNING: Disabling antiforgery protection may make // your APIs vulnerable to CSRF attacks @@ -165,7 +165,7 @@ public class SampleApiController : ControllerBase In *version 2.x*, use the *SkipAntiforgery* fluent API when adding the endpoint. For example: -```csharp +``` app.UseEndpoints(endpoints => { // MVC controllers @@ -188,7 +188,7 @@ app.UseEndpoints(endpoints => MVC controllers and actions can use the *BffApiSkipAntiforgeryAttribute* (which is independent of the *BffApiAttribute*), like this: -```csharp +``` [Route("sample")] // WARNING: Disabling antiforgery protection may make // your APIs vulnerable to CSRF attacks diff --git a/IdentityServer/v6/docs/content/bff/apis/remote.md b/IdentityServer/v6/docs/content/bff/apis/remote.md index a9c72147..7df6eb31 100644 --- a/IdentityServer/v6/docs/content/bff/apis/remote.md +++ b/IdentityServer/v6/docs/content/bff/apis/remote.md @@ -17,7 +17,7 @@ To enable this feature, add a reference to the *Duende.BFF.Yarp* Nuget package, #### Add Remote API Service to DI -```cs +``` services.AddBff() .AddRemoteApis(); ``` @@ -26,7 +26,7 @@ services.AddBff() #### Map Remote APIs This example routes a local */api/customers* endpoint to a remote API, and forwards the user's access token in the outgoing call: -```cs +``` app.UseEndpoints(endpoints => { endpoints.MapRemoteBffApiEndpoint( diff --git a/IdentityServer/v6/docs/content/bff/apis/yarp.md b/IdentityServer/v6/docs/content/bff/apis/yarp.md index 0a027c24..51a7f10c 100644 --- a/IdentityServer/v6/docs/content/bff/apis/yarp.md +++ b/IdentityServer/v6/docs/content/bff/apis/yarp.md @@ -10,7 +10,7 @@ YARP includes many advanced features such as load balancing, service discovery, #### Adding YARP To enable Duende.BFF's YARP integration, add a reference to the *Duende.BFF.Yarp* Nuget package to your project and add YARP and the BFF's YARP extensions to DI: -```cs +``` services.AddBff(); // adds YARP with BFF extensions @@ -48,7 +48,7 @@ See the Microsoft [documentation](https://microsoft.github.io/reverse-proxy/arti Another option is to configure YARP in code using the in-memory config provider included in the BFF extensions for YARP. The above configuration as code would look like this: -```cs +``` builder.LoadFromMemory( new[] { @@ -108,7 +108,7 @@ Routes that set the *Duende.Bff.Yarp.TokenType* metadata **require** the given t If you are using the code config method, call the *WithAccessToken* extension method to achieve the same thing: -```cs +``` builder.LoadFromMemory( new[] { @@ -153,7 +153,7 @@ This metadata causes the user's access token to be sent with the proxied request If you are using the code config method, call the *WithOptionalUserAccessToken* extension method to achieve the same thing: -```cs +``` builder.LoadFromMemory( new[] { @@ -185,7 +185,7 @@ The value of the header is not important, but its presence, combined with the co You can add the anti-forgery protection to all YARP routes by calling the *AsBffApiEndpoint* extension method: -```cs +``` endpoints.MapReverseProxy() .AsBffApiEndpoint(); @@ -214,7 +214,7 @@ If you need more fine grained control over which routes should enforce the anti- This is also possible in code: -```cs +``` builder.LoadFromMemory( new[] { @@ -239,7 +239,7 @@ You can combine the token management feature with the anti-forgery check. To enforce the presence of the anti-forgery headers, you need to add a middleware to the YARP pipeline: -```cs +``` endpoints.MapReverseProxy(proxyApp => { proxyApp.UseAntiforgeryCheck(); diff --git a/IdentityServer/v6/docs/content/bff/extensibility/http_forwarder.md b/IdentityServer/v6/docs/content/bff/extensibility/http_forwarder.md index ba6d06d6..e080bc63 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/http_forwarder.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/http_forwarder.md @@ -14,7 +14,7 @@ By default, Duende.BFF will create and cache an HTTP client per configured route This invoker is setup like this: -```cs +``` var client = new HttpMessageInvoker(new SocketsHttpHandler { UseProxy = false, @@ -26,7 +26,7 @@ var client = new HttpMessageInvoker(new SocketsHttpHandler If you want to customize the HTTP client for specific paths, you can either implement the *IHttpMessageInvokerFactory* interface or derive from the *DefaultHttpMessageInvokerFactory*, e.g.: -```cs +``` public class MyInvokerFactory : DefaultHttpMessageInvokerFactory { public override HttpMessageInvoker CreateClient(string localPath) @@ -55,7 +55,7 @@ public class MyInvokerFactory : DefaultHttpMessageInvokerFactory ..and override our registration: -```cs +``` services.AddSingleton(); ``` @@ -67,7 +67,7 @@ In the standard configuration, BFF uses the YARP default behavior for forwarding If you want to modify this behavior you can either implement *IHttpTransformerFactory* from scratch: -```cs +``` public interface IHttpTransformerFactory { /// diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/_index.md b/IdentityServer/v6/docs/content/bff/extensibility/management/_index.md index bcc10a02..2621bca7 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/_index.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/_index.md @@ -7,7 +7,7 @@ weight: 10 The behavior of each [management endpoint]({{< ref "/bff/session/management" >}}) is defined in a service. When you add Duende.BFF to DI, a default implementation for every management endpoint gets registered: -```csharp +``` // management endpoints services.AddTransient(); services.AddTransient(); @@ -22,7 +22,7 @@ You can add your own implementation by overriding the default after calling *Add The management endpoint services all inherit from the *IBffEndpointService*, which provides a general-purpose mechanism to add custom logic to the endpoints. -```cs +``` public interface IBffEndpointService { Task ProcessRequestAsync(HttpContext context); diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/back-channel-logout.md b/IdentityServer/v6/docs/content/bff/extensibility/management/back-channel-logout.md index e2156f7d..4ebf23a5 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/back-channel-logout.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/back-channel-logout.md @@ -13,7 +13,7 @@ You can add custom logic to the endpoint by implementing the *IBackchannelLogout *ProcessRequestAsync* is the top level function called in the endpoint service and can be used to add arbitrary logic to the endpoint. -```csharp +``` public class CustomizedBackchannelLogoutService : DefaultBackchannelLogoutService { public override Task ProcessRequestAsync(HttpContext context) @@ -28,7 +28,7 @@ public class CustomizedBackchannelLogoutService : DefaultBackchannelLogoutServic Validation of the incoming request can be customized by overriding one of several virtual methods in the *DefaultBackchannelLogoutService*. *GetTokenValidationParameters* allows you to specify the *[TokenValidationParameters](https://learn.microsoft.com/en-us/dotnet/api/microsoft.identitymodel.tokens.tokenvalidationparameters?view=azure-dotnet)* used to validate the incoming logout token. The default implementation creates token validation parameters based on the authentication scheme's configuration. Your override could begin by calling the base method and then make changes to those parameters or completely customize how token validation parameters are created. For example: -```csharp +``` public class CustomizedBackchannelLogoutService : DefaultBackchannelLogoutService { protected override async Task GetTokenValidationParameters() @@ -46,7 +46,7 @@ If you need more control over the validation of the logout token, you can overri *ValidateLogoutTokenAsync* is the coarsest-grained validation method. It is is responsible for validating the incoming logout token and determining if logout should proceed, based on claims in the token. It returns a *ClaimsIdentity* if logout should proceed or null if it should not. Your override could prevent logout in certain circumstances by returning null. For example: -```csharp +``` public class CustomizedBackchannelLogoutService : DefaultBackchannelLogoutService { protected override async Task ValidateLogoutTokenAsync(string logoutToken) diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/diagnostics.md b/IdentityServer/v6/docs/content/bff/extensibility/management/diagnostics.md index 5f884e38..cfb2d4aa 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/diagnostics.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/diagnostics.md @@ -12,7 +12,7 @@ The BFF diagnostics endpoint can be customized by implementing the *IDiagnostics For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/login.md b/IdentityServer/v6/docs/content/bff/extensibility/management/login.md index 202cd974..d4578ac5 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/login.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/login.md @@ -12,7 +12,7 @@ The BFF login endpoint has extensibility points in two interfaces. The *ILoginSe For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/logout.md b/IdentityServer/v6/docs/content/bff/extensibility/management/logout.md index 9f679e01..ff5a226e 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/logout.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/logout.md @@ -12,7 +12,7 @@ The BFF logout endpoint has extensibility points in two interfaces. The *Ilogout For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login-callback.md b/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login-callback.md index a674d7b0..c07aaba3 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login-callback.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login-callback.md @@ -12,7 +12,7 @@ The BFF silent login callback endpoint can be customized by implementing the *IS For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login.md b/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login.md index 57f586b0..40551a2a 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/silent-login.md @@ -12,7 +12,7 @@ The BFF silent login endpoint can be customized by implementing the *ISilentLogi For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here diff --git a/IdentityServer/v6/docs/content/bff/extensibility/management/user.md b/IdentityServer/v6/docs/content/bff/extensibility/management/user.md index 7db77cbb..cfa7b7e9 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/management/user.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/management/user.md @@ -12,7 +12,7 @@ The BFF user endpoint can be customized by implementing the *IUserService* or by For example, you could take whatever actions you need before normal processing of the request like this: -```csharp +``` public override Task ProcessRequestAsync(HttpContext context) { // Custom logic here @@ -26,7 +26,7 @@ public override Task ProcessRequestAsync(HttpContext context) For example, you could add additional claims to the user endpoint that would not be part of the session like this: -```csharp +``` protected override IEnumerable GetUserClaims(AuthenticateResult authenticateResult) { var baseClaims = base.GetUserClaims(authenticateResult); diff --git a/IdentityServer/v6/docs/content/bff/extensibility/sessions.md b/IdentityServer/v6/docs/content/bff/extensibility/sessions.md index 6d64e31d..14a1f9fa 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/sessions.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/sessions.md @@ -82,7 +82,7 @@ public void ConfigureServices(IServiceCollection services) The *IUserSessionStoreCleanup* interface is used to model cleaning up expired sessions. -```csharp +``` /// /// User session store cleanup /// diff --git a/IdentityServer/v6/docs/content/bff/extensibility/tokens.md b/IdentityServer/v6/docs/content/bff/extensibility/tokens.md index 99ab86a5..6f0c9243 100644 --- a/IdentityServer/v6/docs/content/bff/extensibility/tokens.md +++ b/IdentityServer/v6/docs/content/bff/extensibility/tokens.md @@ -15,7 +15,7 @@ Both aspects can be customized. ### Token service communication The token management library uses a named HTTP client from the HTTP client factory for all token service communication. You can provide a customized HTTP client yourself using the well-known name after calling *AddBff*: -```cs +``` services.AddHttpClient(AccessTokenManagementDefaults.BackChannelHttpClientName, configureClient => { ... }); ``` @@ -35,7 +35,7 @@ This would involve two steps The interface is responsible to storing, retrieving and clearing tokens for the automatic token management: -```cs +``` public interface IUserAccessTokenStore { /// @@ -71,7 +71,7 @@ public interface IUserAccessTokenStore The token store defines how tokens are retrieved globally. However, you can add custom logic that changes the way that access tokens are retrieved on a per-route basis. For example, you might need to exchange a token to perform delegation or impersonation for some API calls, depending on the remote API. The interface that describes this extension point is the *IAccessTokenRetriever*. -```cs +``` /// /// Retrieves access tokens /// @@ -92,7 +92,7 @@ You can implement this interface yourself or extend the *DefaultAccessTokenRetri Implementations of the *IAccessTokenRetriever* can be added to endpoints when they are mapped using the *WithAccessTokenRetriever* extension method: -```cs +``` endpoints.MapRemoteBffApiEndpoint("/api/impersonation", "https://api.example.com/endpoint/requiring/impersonation") .RequireAccessToken(TokenType.User) .WithAccessTokenRetriever(); diff --git a/IdentityServer/v6/docs/content/bff/options.md b/IdentityServer/v6/docs/content/bff/options.md index 9648d4a7..85f6dde8 100644 --- a/IdentityServer/v6/docs/content/bff/options.md +++ b/IdentityServer/v6/docs/content/bff/options.md @@ -9,7 +9,7 @@ The *Duende.BFF.BffOptions* allows to configure several aspects of the BFF frame You set the options at startup time in your *ConfigureServices* method: -```cs +``` services.AddBff(options => { // configure options here.. diff --git a/IdentityServer/v6/docs/content/bff/session/handlers.md b/IdentityServer/v6/docs/content/bff/session/handlers.md index c2b4b6ac..47529e7e 100644 --- a/IdentityServer/v6/docs/content/bff/session/handlers.md +++ b/IdentityServer/v6/docs/content/bff/session/handlers.md @@ -13,7 +13,7 @@ Furthermore the BFF plumbing relies on the configuration of the ASP.NET Core def OpenID Connect for *challenge* and *signout* - cookies for all the other operations: -```csharp +``` services.AddAuthentication(options => { options.DefaultScheme = "cookie"; @@ -36,7 +36,7 @@ The exact settings depend on the OIDC provider and its configuration settings. W * save the tokens into the authentication session so they can be automatically managed * request a refresh token using the *offline_access* scope -```csharp +``` services.AddAuthentication().AddOpenIdConnect("oidc", options => { options.Authority = "https://demo.duendesoftware.com"; @@ -78,7 +78,7 @@ Things to consider: * it is recommended to use a cookie name [prefix](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-4.1.3) if compatible with your application * use the highest available *SameSite* mode that is compatible with your application, e.g. *strict*, but at least *lax* -```csharp +``` services.AddAuthentication().AddCookie("cookie", options => { // set session lifetime diff --git a/IdentityServer/v6/docs/content/bff/session/management/_index.md b/IdentityServer/v6/docs/content/bff/session/management/_index.md index 181efa84..2e8eaf1a 100644 --- a/IdentityServer/v6/docs/content/bff/session/management/_index.md +++ b/IdentityServer/v6/docs/content/bff/session/management/_index.md @@ -10,7 +10,7 @@ In addition Duende.BFF adds an implementation of the OpenID Connect back-channel You enable the endpoints by adding the relevant services into the DI container: -```csharp +``` public void ConfigureServices(IServiceCollection services) { // Add BFF services to DI - also add server-side session management @@ -26,7 +26,7 @@ public void ConfigureServices(IServiceCollection services) Endpoint routing is used to map the management endpoints: -```csharp +``` public void Configure(IApplicationBuilder app) { // rest omitted diff --git a/IdentityServer/v6/docs/content/bff/session/management/login.md b/IdentityServer/v6/docs/content/bff/session/management/login.md index ad73d7af..770be8c6 100644 --- a/IdentityServer/v6/docs/content/bff/session/management/login.md +++ b/IdentityServer/v6/docs/content/bff/session/management/login.md @@ -13,7 +13,7 @@ window.location = "/bff/login"; In Blazor, instead use the *NavigationManager* to navigate to the login endpoint: -```cs +``` Navigation.NavigateTo($"bff/login", forceLoad: true); ``` diff --git a/IdentityServer/v6/docs/content/bff/session/server_side_sessions.md b/IdentityServer/v6/docs/content/bff/session/server_side_sessions.md index 0726e8c0..867922ba 100644 --- a/IdentityServer/v6/docs/content/bff/session/server_side_sessions.md +++ b/IdentityServer/v6/docs/content/bff/session/server_side_sessions.md @@ -15,7 +15,7 @@ Duende.BFF includes all the plumbing to store your sessions server-side. The coo Server-side session can be enabled in *Startup*: -```csharp +``` services.AddBff() .AddServerSideSessions(); ``` @@ -26,7 +26,7 @@ The default implementation stores the session in-memory. This is useful for test To use the EF session store, register it by calling *AddEntityFrameworkServerSideSessions*, like this: -```csharp +``` var cn = _configuration.GetConnectionString("db"); services.AddBff() @@ -46,7 +46,7 @@ Added in v1.2.0. Abandoned sessions will remain in the store unless something removes the stale entries. If you wish to have such sessions cleaned up periodically, then you can configure the *EnableSessionCleanup* and *SessionCleanupInterval* options: -```csharp +``` services.AddBff(options => { options.EnableSessionCleanup = true; options.SessionCleanupInterval = TimeSpan.FromMinutes(5); @@ -59,7 +59,7 @@ This requires an implementation of [*IUserSessionStoreCleanup*]({{< ref "/bff/ex If using Entity Framework Core, then the *IUserSessionStoreCleanup* implementation is provided for you when you use *AddEntityFrameworkServerSideSessions*. Just enable session cleanup: -```csharp +``` var cn = _configuration.GetConnectionString("db"); services.AddBff(options => { diff --git a/IdentityServer/v6/docs/content/bff/tokens.md b/IdentityServer/v6/docs/content/bff/tokens.md index c35f2fd2..a27a0ab5 100644 --- a/IdentityServer/v6/docs/content/bff/tokens.md +++ b/IdentityServer/v6/docs/content/bff/tokens.md @@ -11,20 +11,20 @@ For most scenarios, there is no additional configuration necessary. The token ma The easiest way to retrieve the current access token is to use an extension method on *HttpContext*: -```cs +``` var token = await HttpContext.GetUserAccessTokenAsync(); ``` You can then use the token to set it on an *HttpClient* instance: -```cs +``` var client = new HttpClient(); client.SetBearerToken(token); ``` We recommend to leverage the *HttpClientFactory* to fabricate HTTP clients that are already aware of the token management plumbing. For this you would register a named client in your *startup* e.g. like this: -```cs +``` // registers HTTP client that uses the managed user access token services.AddUserAccessTokenHttpClient("apiClient", configureClient: client => { @@ -34,7 +34,7 @@ services.AddUserAccessTokenHttpClient("apiClient", configureClient: client => And then retrieve a client instance like this: -```cs +``` [Route("myApi")] public class MyApiController : ControllerBase { @@ -60,7 +60,7 @@ public class MyApiController : ControllerBase If you prefer to use typed clients, you can do that as well: -```cs +``` // registers a typed HTTP client with token management support services.AddHttpClient(client => { @@ -71,7 +71,7 @@ services.AddHttpClient(client => And then use that client, for example like this on a controller's action method: -```cs +``` public async Task CallApiAsUserTyped( [FromServices] MyTypedClient client) { @@ -91,7 +91,7 @@ Duende.BFF revokes refresh tokens automatically at logout time. This behavior ca If you want to manually revoke the current refresh token, you can use the following code: -```cs +``` await HttpContext.RevokeUserRefreshTokenAsync(); ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/installation.md b/IdentityServer/v6/docs/content/configuration/dcr/installation.md index aaf5903d..9bfd9678 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/installation.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/installation.md @@ -26,7 +26,7 @@ dotnet add package Duende.IdentityServer.Configuration ``` #### Configure Services -```cs +``` builder.Services.AddIdentityServerConfiguration(opt => opt.LicenseKey = ""; ); @@ -49,7 +49,7 @@ package and add it to DI. dotnet add package Duende.IdentityServer.Configuration.EntityFramework ``` -```cs +``` builder.Services.AddIdentityServerConfiguration(opt => opt.LicenseKey = "" ).AddClientConfigurationStore(); @@ -61,7 +61,7 @@ builder.Services.AddConfigurationDbContext(options => ``` #### Map Configuration Endpoints -```cs +``` app.MapDynamicClientRegistration().RequireAuthorization("DCR"); ``` *MapDynamicClientRegistration* registers the DCR endpoints and returns an @@ -78,7 +78,7 @@ dotnet add package Duende.IdentityServer.Configuration ``` #### Add the Configuration API's services to the service collection: -```cs +``` builder.Services.AddIdentityServerConfiguration(); ``` @@ -96,7 +96,7 @@ package and add it to DI. dotnet add package Duende.IdentityServer.Configuration.EntityFramework ``` -```cs +``` builder.Services.AddIdentityServerConfiguration(opt => opt.LicenseKey = "" ).AddClientConfigurationStore(); @@ -107,7 +107,7 @@ builder.Services.AddConfigurationDbContext(options => }); ``` #### Map Configuration Endpoints: -```cs +``` app.MapDynamicClientRegistration().RequireAuthorization("DCR"); ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/models.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/models.md index 0fca1111..3bfb897d 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/models.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/models.md @@ -7,7 +7,7 @@ weight: 50 ## DynamicClientRegistrationRequest Represents a dynamic client registration request. The parameters that are supported include a subset of the parameters [defined by IANA](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata), and custom properties needed by IdentityServer. -```csharp +``` public class DynamicClientRegistrationRequest ``` @@ -57,7 +57,7 @@ public class DynamicClientRegistrationRequest ## Dynamic Client Registration Response Represents the response to a successful dynamic client registration request. This class extends the registration request by adding additional properties that are generated server side and not set by the client. -```csharp +``` public class DynamicClientRegistrationResponse : DynamicClientRegistrationRequest, IDynamicClientRegistrationResponse ``` @@ -75,7 +75,7 @@ the original DCR request, the client model that is built up through validation and processing, the caller who made the DCR request, and other contextual information. -```csharp +``` public class DynamicClientRegistrationContext ``` @@ -92,7 +92,7 @@ Represents an error that occurred during validation of a dynamic client registration request. This class implements the appropriate [marker interfaces](#marker-interfaces) so that it can be returned from various points in the validator or processor. -```csharp +``` public class DynamicClientRegistrationValidationError : IStepResult, IDynamicClientRegistrationResponse, IDynamicClientRegistrationValidationResult ``` @@ -140,13 +140,13 @@ conveniently construct a success or failure from a step wrapped in a task. ## DynamicClientRegistrationValidatedRequest Represents a successfully validated dynamic client registration request. -```csharp +``` public class DynamicClientRegistrationValidatedRequest : DynamicClientRegistrationValidationResult ``` ## SuccessfulStep Represents a successful validation step. -```csharp +``` public class SuccessfulStep : IStepResult ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/options.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/options.md index 6d97fc55..5f2537e8 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/options.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/options.md @@ -7,7 +7,7 @@ weight: 60 Top level options for IdentityServer.Configuration. -```csharp +``` public class IdentityServerConfigurationOptions ``` @@ -21,7 +21,7 @@ public class IdentityServerConfigurationOptions Options for dynamic client registration. -```csharp +``` public class DynamicClientRegistrationOptions ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/processing.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/processing.md index 4d32ba87..6ab535d4 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/processing.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/processing.md @@ -28,7 +28,7 @@ The *DynamicClientRegistrationRequestProcessor* is the default implementation of of Dynamic Client Registration request processing, we recommend that you extend this class and override the appropriate virtual methods. -```csharp +``` public class DynamicClientRegistrationRequestProcessor : IDynamicClientRegistrationRequestProcessor ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/response.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/response.md index 8c0601f6..7d1dbbd9 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/response.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/response.md @@ -8,7 +8,7 @@ weight: 40 The *IDynamicClientRegistrationResponseGenerator* interface defines the contract for a service that generates dynamic client registration responses. -```csharp +``` public interface IDynamicClientRegistrationResponseGenerator ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/store.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/store.md index 45e3e93c..22c344bc 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/store.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/store.md @@ -10,7 +10,7 @@ The *IClientConfigurationStore* interface defines the contract for a service that communication with the client configuration data store. It contains a single *AddAsync* method. -```csharp +``` public interface IClientConfigurationStore ``` diff --git a/IdentityServer/v6/docs/content/configuration/dcr/reference/validation.md b/IdentityServer/v6/docs/content/configuration/dcr/reference/validation.md index 7a8a08b9..998d1d23 100644 --- a/IdentityServer/v6/docs/content/configuration/dcr/reference/validation.md +++ b/IdentityServer/v6/docs/content/configuration/dcr/reference/validation.md @@ -20,7 +20,7 @@ itself. Validates a dynamic client registration request. -```csharp +``` public Task ValidateAsync( DynamicClientRegistrationContext context) ``` @@ -35,7 +35,7 @@ A task that returns an [*IDynamicClientRegistrationValidationResult*]({{< ref ". ## DynamicClientRegistrationValidator -```csharp +``` public class DynamicClientRegistrationValidator : IDynamicClientRegistrationValidator ``` diff --git a/IdentityServer/v6/docs/content/data/configuration.md b/IdentityServer/v6/docs/content/data/configuration.md index 530464c6..880fb3eb 100644 --- a/IdentityServer/v6/docs/content/data/configuration.md +++ b/IdentityServer/v6/docs/content/data/configuration.md @@ -20,7 +20,7 @@ Custom implementations of the stores must be registered in the DI system. There are [convenience methods]({{}}) for registering these. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -40,7 +40,7 @@ Duende IdentityServer provides [convenience methods]({{* service and must also be added to DI. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -58,7 +58,7 @@ public void ConfigureServices(IServiceCollection services) The duration of the data in the default cache is configurable on the [IdentityServerOptions]({{}}). For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(options => { diff --git a/IdentityServer/v6/docs/content/data/ef.md b/IdentityServer/v6/docs/content/data/ef.md index cd729e5f..6882b240 100644 --- a/IdentityServer/v6/docs/content/data/ef.md +++ b/IdentityServer/v6/docs/content/data/ef.md @@ -24,7 +24,7 @@ These implementations use a *DbContext*-derived class called *ConfigurationDbCon To use the configuration store support, use the *AddConfigurationStore* extension method after the call to *AddIdentityServer*: -```csharp +``` public IServiceProvider ConfigureServices(IServiceCollection services) { const string connectionString = @"Data Source=(LocalDb)\MSSQLLocalDB;database=YourIdentityServerDatabase;trusted_connection=yes;"; @@ -53,13 +53,13 @@ This options class contains properties to control the configuration store and *C *DefaultSchema* Allows setting the default database schema name for all the tables in the *ConfigurationDbContext* -```csharp +``` options.DefaultSchema = "myConfigurationSchema"; ``` If you need to change the schema for the Migration History Table, you can chain another action to the *UseSqlServer*: -```csharp +``` options.ConfigureDbContext = b => b.UseSqlServer(connectionString, sql => sql.MigrationsAssembly(migrationsAssembly).MigrationsHistoryTable("MyConfigurationMigrationTable", "myConfigurationSchema")); @@ -69,7 +69,7 @@ options.ConfigureDbContext = b => To enable caching for the EF configuration store implementation, use the *AddConfigurationStoreCache* extension method: -```csharp +``` public IServiceProvider ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -86,7 +86,7 @@ The implementation uses a *DbContext*-derived class called *PersistedGrantDbCont To use the operational store support, use the *AddOperationalStore* extension method after the call to *AddIdentityServer*: -```csharp +``` public IServiceProvider ConfigureServices(IServiceCollection services) { const string connectionString = @"Data Source=(LocalDb)\MSSQLLocalDB;database=YourIdentityServerDatabase;trusted_connection=yes;"; diff --git a/IdentityServer/v6/docs/content/data/operational/grants.md b/IdentityServer/v6/docs/content/data/operational/grants.md index d685e4ca..03ec4dfe 100644 --- a/IdentityServer/v6/docs/content/data/operational/grants.md +++ b/IdentityServer/v6/docs/content/data/operational/grants.md @@ -17,7 +17,7 @@ The persistence for grants is abstracted behind two interfaces: Custom implementations of *IPersistedGrantStore*, and/or *IDeviceFlowStore* must be registered in the DI system. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(); diff --git a/IdentityServer/v6/docs/content/data/operational/keys.md b/IdentityServer/v6/docs/content/data/operational/keys.md index d3a70a25..d09cf46a 100644 --- a/IdentityServer/v6/docs/content/data/operational/keys.md +++ b/IdentityServer/v6/docs/content/data/operational/keys.md @@ -14,7 +14,7 @@ The [ISigningKeyStore]({{}}) is that To register a custom signing key store in the DI container, there is a *AddSigningKeyStore* helper on the *IIdentityServerBuilder*. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() diff --git a/IdentityServer/v6/docs/content/data/operational/sessions.md b/IdentityServer/v6/docs/content/data/operational/sessions.md index 1181eb33..38bce8bb 100644 --- a/IdentityServer/v6/docs/content/data/operational/sessions.md +++ b/IdentityServer/v6/docs/content/data/operational/sessions.md @@ -21,7 +21,7 @@ To register a custom server-side session store in the DI container, there is a * It is still necessary to call *AddServerSideSessions* to enable the server-side session feature. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -33,7 +33,7 @@ public void ConfigureServices(IServiceCollection services) There is also an overloaded version of a *AddServerSideSessions* that will perform both registration steps in one call. For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -49,7 +49,7 @@ When using the EntityFramework Core operational store, it will be necessary to i For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() diff --git a/IdentityServer/v6/docs/content/deployment/data_protection.md b/IdentityServer/v6/docs/content/deployment/data_protection.md index 82083789..e39b5b72 100644 --- a/IdentityServer/v6/docs/content/deployment/data_protection.md +++ b/IdentityServer/v6/docs/content/deployment/data_protection.md @@ -10,7 +10,7 @@ In local development, ASP.NET automatically creates data protection keys, but in A typical IdentityServer implementation should include data protection configuration code, like this: -```cs +``` builder.Services.AddDataProtection() // Choose an extension method for key persistence, such as // PersistKeysToFileSystem, PersistKeysToDbContext, diff --git a/IdentityServer/v6/docs/content/diagnostics/events.md b/IdentityServer/v6/docs/content/diagnostics/events.md index aee7065d..9a71e406 100644 --- a/IdentityServer/v6/docs/content/diagnostics/events.md +++ b/IdentityServer/v6/docs/content/diagnostics/events.md @@ -13,7 +13,7 @@ Events work great with structured logging stores like [ELK](https://www.elastic. ### Emitting events Events are not turned on by default - but can be globally configured in the *ConfigureServices* method, e.g.: -```cs +``` services.AddIdentityServer(options => { options.Events.RaiseSuccessEvents = true; @@ -24,7 +24,7 @@ services.AddIdentityServer(options => To emit an event use the *IEventService* from the DI container and call the *RaiseAsync* method, e.g.: -```cs +``` public async Task Login(LoginInputModel model) { if (_users.ValidateCredentials(model.Username, model.Password)) @@ -46,7 +46,7 @@ If you want to connect to a custom event store, implement the *IEventSink* inter The following example uses [Seq](https://getseq.net) to emit events: -```cs +``` public class SeqEventSink : IEventSink { private readonly Logger _log; @@ -132,7 +132,7 @@ You can create your own events and emit them via our infrastructure. You need to derive from our base *Event* class which injects contextual information like activity ID, timestamp, etc. Your derived class can then add arbitrary data fields specific to the event context:: -```cs +``` public class UserLoginFailureEvent : Event { public UserLoginFailureEvent(string username, string error) diff --git a/IdentityServer/v6/docs/content/diagnostics/logging.md b/IdentityServer/v6/docs/content/diagnostics/logging.md index f6feb8df..1e0a4c77 100644 --- a/IdentityServer/v6/docs/content/diagnostics/logging.md +++ b/IdentityServer/v6/docs/content/diagnostics/logging.md @@ -41,7 +41,7 @@ In production, logging might produce too much data. It is recommended you either ### Setup for Serilog We personally like [Serilog](https://serilog.net) and the [Serilog.AspNetCore](https://github.com/serilog/serilog-aspnetcore) package a lot. Give it a try: -```cs +``` public class Program { public static int Main(string[] args) diff --git a/IdentityServer/v6/docs/content/diagnostics/otel.md b/IdentityServer/v6/docs/content/diagnostics/otel.md index a472b475..691427a9 100644 --- a/IdentityServer/v6/docs/content/diagnostics/otel.md +++ b/IdentityServer/v6/docs/content/diagnostics/otel.md @@ -34,7 +34,7 @@ To start emitting Otel tracing information you need * add the Otel libraries to your IdentityServer and client applications * start collecting traces from the various IdentityServer sources (and other sources e.g. ASP.NET Core) -```cs +``` builder.Services.AddOpenTelemetryTracing(builder => { builder diff --git a/IdentityServer/v6/docs/content/fundamentals/claims.md b/IdentityServer/v6/docs/content/fundamentals/claims.md index 90416e89..01174bcc 100644 --- a/IdentityServer/v6/docs/content/fundamentals/claims.md +++ b/IdentityServer/v6/docs/content/fundamentals/claims.md @@ -35,7 +35,7 @@ The *RequestedClaimTypes* property of the *ProfileDataRequestContext* contains t If your profile service extends the *DefaultProfileService*, you can use its *AddRequestedClaims* method to add only requested and approved claims. The intent is that your profile service can retrieve claim data and then filter that claim data based on what was requested by the client. For example: -```cs +``` public class SampleProfileService : DefaultProfileService { public virtual async Task GetProfileDataAsync(ProfileDataRequestContext context) @@ -56,7 +56,7 @@ public class SampleProfileService : DefaultProfileService #### Always emit claims We generally recommend emitting claims based on the requested claim types, as that respects the scopes and resources requested by the client and gives the end user an opportunity to consent to this sharing of information. However, if you have claims that don't need to follow such rules, such as claims that are an integral part of the user's identity and that are needed in most scenarios, they can be added by directly updating the *context.IssuedClaims* collection. For example: -```cs +``` public class SampleProfileService : DefaultProfileService { public virtual async Task GetProfileDataAsync(ProfileDataRequestContext context) @@ -84,7 +84,7 @@ When the profile service is called for requests to the [userinfo endpoint]({{< r ## Client claims Client claims are a set of pre-defined claims that are emitted in access tokens. They are defined on a per-client basis, meaning that each client can have its own unique set of client claims. The following shows an example of a client that is associated with a certain customer in your system: -```cs +``` var client = new Client { ClientId = "client", diff --git a/IdentityServer/v6/docs/content/fundamentals/clients.md b/IdentityServer/v6/docs/content/fundamentals/clients.md index 99e594a5..d49e0107 100644 --- a/IdentityServer/v6/docs/content/fundamentals/clients.md +++ b/IdentityServer/v6/docs/content/fundamentals/clients.md @@ -18,7 +18,7 @@ The details vary, but you typically define the following common settings for a c ## Defining a client for server to server communication In this scenario no interactive user is present - a service (i.e. the client) wants to communicate with an API (i.e. the resource that supports the scope): -```cs +``` public class Clients { public static IEnumerable Get() @@ -42,7 +42,7 @@ public class Clients Interactive applications (e.g. web applications or native desktop/mobile) applications use the authorization code flow. This flow gives you the best security because the access tokens are transmitted via back-channel calls only (and gives you access to refresh tokens): -```cs +``` var interactiveClient = new Client { ClientId = "interactive", @@ -86,6 +86,6 @@ The *AddInMemoryClients* extensions method also supports adding clients from the Then pass the configuration section to the *AddInMemoryClients* method: -```cs +``` AddInMemoryClients(configuration.GetSection("IdentityServer:Clients")) ``` diff --git a/IdentityServer/v6/docs/content/fundamentals/hosting.md b/IdentityServer/v6/docs/content/fundamentals/hosting.md index 455f362c..177079f6 100644 --- a/IdentityServer/v6/docs/content/fundamentals/hosting.md +++ b/IdentityServer/v6/docs/content/fundamentals/hosting.md @@ -12,7 +12,7 @@ While technically you could share the ASP.NET Core host between Duende IdentityS ## DI system You add the necessary services to the DI system by calling *AddIdentityServer* in your startup class: -```cs +``` public void ConfigureServices(IServiceCollection services) { var builder = services.AddIdentityServer(options => { ... }); @@ -24,7 +24,7 @@ Many of the fundamental configuration settings can be set on the options. See th The builder object has a number of extension methods to add additional services to DI. You can see the full list in the [reference]({{< ref "/reference/di" >}}) section, but very commonly you start by adding the configuration stores for clients and resources, e.g.: -```cs +``` var builder = services.AddIdentityServer() .AddInMemoryClients(Config.Clients) .AddInMemoryIdentityResources(Config.IdentityResources) @@ -40,7 +40,7 @@ Since ordering is important in the pipeline, you typically want to put the Ident This would be a very typical minimal pipeline: -```cs +``` public void Configure(IApplicationBuilder app) { app.UseStaticFiles(); diff --git a/IdentityServer/v6/docs/content/fundamentals/keys/automatic_key_management.md b/IdentityServer/v6/docs/content/fundamentals/keys/automatic_key_management.md index fac46b0a..d72c4c32 100644 --- a/IdentityServer/v6/docs/content/fundamentals/keys/automatic_key_management.md +++ b/IdentityServer/v6/docs/content/fundamentals/keys/automatic_key_management.md @@ -37,7 +37,7 @@ propagation time, retain old keys for a duration of 14 days, and to delete keys when they are retired. All of these options are configurable in the *KeyManagement* options. For example: -```cs +``` var builder = services.AddIdentityServer(options => { // new key every 30 days @@ -72,7 +72,7 @@ If you are deploying in a load balanced environment and wish to use the *FileSystemKeyStore*, all instances of IdentityServer will need read/write access to the *KeyPath*. -```cs +``` var builder = services.AddIdentityServer(options => { // set path to store keys @@ -101,7 +101,7 @@ multiple keys, algorithms, and if those keys should additionally get wrapped in an X.509 certificate. Automatic key management will create and rotate keys for each signing algorithm you specify. -```cs +``` options.KeyManagement.SigningAlgorithms = new[] { // RS256 for older clients (with additional X.509 wrapping) diff --git a/IdentityServer/v6/docs/content/fundamentals/keys/migration.md b/IdentityServer/v6/docs/content/fundamentals/keys/migration.md index fc7fe6dd..3918a335 100644 --- a/IdentityServer/v6/docs/content/fundamentals/keys/migration.md +++ b/IdentityServer/v6/docs/content/fundamentals/keys/migration.md @@ -36,7 +36,7 @@ as the signing credential. In this phase, the new automatically managed key will announced so that as client apps and APIs update their caches, they get the new key. IdentityServer will continue to sign keys with your old static key. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = true; @@ -54,7 +54,7 @@ then proceed to phase 2. Next, switch to using the new automatically managed keys for signing, but still keep the old key for validation purposes. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = true; @@ -70,7 +70,7 @@ expired, and then proceed to phase 3. ## Phase 3: Drop the old key Now the static key configuration can be removed entirely. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = true; diff --git a/IdentityServer/v6/docs/content/fundamentals/keys/static_key_management.md b/IdentityServer/v6/docs/content/fundamentals/keys/static_key_management.md index 40ba11e7..540f50c4 100644 --- a/IdentityServer/v6/docs/content/fundamentals/keys/static_key_management.md +++ b/IdentityServer/v6/docs/content/fundamentals/keys/static_key_management.md @@ -16,7 +16,7 @@ The automatic key management feature can be disabled by setting the *Enabled* flag to *false* on the the *KeyManagement* property of [*IdentityServerOptions*]({{< ref "/reference/options#key-management" >}}): -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = false; @@ -36,7 +36,7 @@ include: Signing keys are added with the [*AddSigningCredential*]({{< ref "/reference/di#signing-keys" >}}) configuration method: -```cs +``` var builder = services.AddIdentityServer(); var key = LoadKeyFromVault(); // (Your code here) builder.AddSigningCredential(key, SecurityAlgorithms.RsaSha256); @@ -99,7 +99,7 @@ all the applications and APIs to update their caches without any interruption in service. Configure IdentityServer for phase 1 by registering the new key as a validation key. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = false; @@ -127,7 +127,7 @@ 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 the signing credential and validation key. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = false; @@ -149,7 +149,7 @@ defaults to 1 hour, though it is configurable. Once enough time has passed that there are no unexpired tokens signed with the old key, it is safe to completely remove the old key. -```cs +``` var builder = services.AddIdentityServer(options => { options.KeyManagement.Enabled = false; diff --git a/IdentityServer/v6/docs/content/fundamentals/license_key.md b/IdentityServer/v6/docs/content/fundamentals/license_key.md index fec27000..62e8ac41 100644 --- a/IdentityServer/v6/docs/content/fundamentals/license_key.md +++ b/IdentityServer/v6/docs/content/fundamentals/license_key.md @@ -22,7 +22,7 @@ The *LicenseKey* is one such setting. The contents of the license key file is text, and so that is the value to assign to the *LicenseKey* property. For example: -```csharp +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(options => diff --git a/IdentityServer/v6/docs/content/fundamentals/resources/api_resources.md b/IdentityServer/v6/docs/content/fundamentals/resources/api_resources.md index 3fb21ea9..724663f2 100644 --- a/IdentityServer/v6/docs/content/fundamentals/resources/api_resources.md +++ b/IdentityServer/v6/docs/content/fundamentals/resources/api_resources.md @@ -11,7 +11,7 @@ In Duende IdentityServer, the *ApiResource* class allows for some additional org Let's use the following scope definition as an example: -```cs +``` public static IEnumerable GetApiScopes() { return new List @@ -33,7 +33,7 @@ public static IEnumerable GetApiScopes() With *ApiResource* you can now create two logical APIs and their corresponding scopes: -```cs +``` public static readonly IEnumerable GetApiResources() { return new List @@ -108,7 +108,7 @@ Client requests: **manage**: ### Adding user claims You can specify that an access token for an API resource (regardless of which scope is requested) should contain additional user claims. -```cs +``` var customerResource = new ApiResource("customer", "Customer API") { Scopes = { "customer.read", "customer.contact", "manage", "enumerate" }, @@ -146,7 +146,7 @@ An example could be regulatory requirements, or that you are starting to migrate The following sample sets *PS256* as the required signing algorithm for the *invoices* API: -```cs +``` var invoiceApi = new ApiResource("invoice", "Invoice API") { Scopes = { "invoice.read", "invoice.pay", "manage", "enumerate" }, diff --git a/IdentityServer/v6/docs/content/fundamentals/resources/api_scopes.md b/IdentityServer/v6/docs/content/fundamentals/resources/api_scopes.md index 28f3b997..117eeb57 100644 --- a/IdentityServer/v6/docs/content/fundamentals/resources/api_scopes.md +++ b/IdentityServer/v6/docs/content/fundamentals/resources/api_scopes.md @@ -20,7 +20,7 @@ Let's model something very simple - a system that has three logical operations * You can define them using the *ApiScope* class: -```cs +``` public static IEnumerable GetApiScopes() { return new List @@ -34,7 +34,7 @@ public static IEnumerable GetApiScopes() You can then assign the scopes to various clients, e.g.: -```cs +``` var webViewer = new Client { ClientId = "web_viewer", @@ -100,7 +100,7 @@ Sometimes scopes have a certain structure, e.g. a scope name with an additional In this case you would create a scope without the parameter part and assign that name to a client, but in addition provide some logic to parse the structure of the scope at runtime using the *IScopeParser* interface or by deriving from our default implementation, e.g.: -```cs +``` public class ParameterizedScopeParser : DefaultScopeParser { public ParameterizedScopeParser(ILogger logger) : base(logger) @@ -144,7 +144,7 @@ public class ParameterizedScopeParser : DefaultScopeParser You then have access to the parsed value throughout the pipeline, e.g. in the profile service: -```cs +``` public class HostProfileService : IProfileService { public override async Task GetProfileDataAsync(ProfileDataRequestContext context) diff --git a/IdentityServer/v6/docs/content/fundamentals/resources/identity.md b/IdentityServer/v6/docs/content/fundamentals/resources/identity.md index 7d1f7b96..664f1315 100644 --- a/IdentityServer/v6/docs/content/fundamentals/resources/identity.md +++ b/IdentityServer/v6/docs/content/fundamentals/resources/identity.md @@ -13,7 +13,7 @@ One of them is actually mandatory, the *openid* scope, which tells the provider This is how you could define the openid scope in code: -```cs +``` public static IEnumerable GetIdentityResources() { return new List @@ -28,7 +28,7 @@ public static IEnumerable GetIdentityResources() But since this is one of the standard scopes from the spec you can shorten that to: -```cs +``` public static IEnumerable GetIdentityResources() { return new List @@ -43,7 +43,7 @@ See the [reference]({{< ref "/reference/models/identity_resource" >}}) section f The following example shows a custom identity resource called *profile* that represents the display name, email address and website claim: -```cs +``` public static IEnumerable GetIdentityResources() { return new List @@ -58,7 +58,7 @@ public static IEnumerable GetIdentityResources() Once the resource is defined, you can give access to it to a client via the *AllowedScopes* option (other properties omitted): -```cs +``` var client = new Client { ClientId = "client", diff --git a/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md b/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md index 07adc991..6840d5aa 100644 --- a/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md +++ b/IdentityServer/v6/docs/content/fundamentals/resources/isolation.md @@ -22,7 +22,7 @@ To solve this problem [RFC 8707](https://tools.ietf.org/html/rfc8707) adds an ad ## Using the resource parameter Let's assume you have the following resource design and that the client is allowed access to all scopes: -```cs +``` var resources = new[] { new ApiResource("urn:invoices") @@ -123,7 +123,7 @@ The end-result will be that the client has two access tokens - one for each reso ## Enforcing resource isolation All examples so far used the *resource* parameter optionally. If you have API resources, where you want to make sure they are not sharing access tokens with other resources, you can enforce the resource indicator, e.g.: -```cs +``` var resources = new[] { new ApiResource("urn:invoices") diff --git a/IdentityServer/v6/docs/content/overview/big_picture.md b/IdentityServer/v6/docs/content/overview/big_picture.md index ee08913f..1f8089c4 100644 --- a/IdentityServer/v6/docs/content/overview/big_picture.md +++ b/IdentityServer/v6/docs/content/overview/big_picture.md @@ -1,5 +1,5 @@ --- -title: "The big Picture" +title: "The Big Picture" date: 2020-09-10T08:22:12+02:00 weight: 1 --- diff --git a/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md b/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md index 40247795..de411482 100644 --- a/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md +++ b/IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md @@ -116,7 +116,8 @@ Scope definitions can be loaded in many ways. This quickstart shows how to use a template at *src/IdentityServer/Config.cs*. Open it and add an *ApiScope* to the *ApiScopes* property: -```csharp + +``` public static IEnumerable ApiScopes => new List { @@ -145,7 +146,7 @@ authenticate with IdentityServer using a client secret. Add this client definition to *Config.cs*: -```cs +``` public static IEnumerable Clients => new List { @@ -187,7 +188,7 @@ the scopes and clients. You can take a look to see how it is done. Note that the template adds a few things that are not used in this quickstart. Here's the minimal ConfigureServices method that is needed: -```csharp +``` public static WebApplication ConfigureServices(this WebApplicationBuilder builder) { builder.Services.AddIdentityServer() @@ -260,7 +261,7 @@ Now add JWT Bearer authentication services to the Service Collection to allow for dependency injection (DI), and configure *Bearer* as the default [Authentication Scheme](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?view=aspnetcore-6.0#authentication-scheme). -```csharp +``` builder.Services.AddAuthentication("Bearer") .AddJwtBearer("Bearer", options => { @@ -283,7 +284,7 @@ more in-depth discussion. {{% /notice %}} Add authentication middleware to the pipeline immediately before authorization: -```csharp +``` app.UseAuthentication(); app.UseAuthorization(); ``` @@ -295,7 +296,7 @@ endpoint cannot be accessed by anonymous clients. ### Add a controller Add a new class called *IdentityController* in *src/Api/Controllers*: -```csharp +``` [Route("identity")] [Authorize] public class IdentityController : ControllerBase @@ -366,7 +367,7 @@ way you only need to know the base address of IdentityServer - the actual endpoint addresses can be read from the metadata. Add the following to the client's Program.cs in the *src/Client/Program.cs* directory: -```cs +``` // discover endpoints from metadata var client = new HttpClient(); var disco = await client.GetDiscoveryDocumentAsync("https://localhost:5001"); @@ -390,7 +391,7 @@ only needs to be done once. Next you can use the information from the discovery document to request a token from *IdentityServer* to access *api1*: -```cs +``` // request token var tokenResponse = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest { @@ -421,7 +422,7 @@ inspect the raw token. To send the access token to the API you typically use the HTTP Authorization header. This is done using the *SetBearerToken* extension method: -```cs +``` // call api var apiClient = new HttpClient(); apiClient.SetBearerToken(tokenResponse.AccessToken); @@ -477,7 +478,7 @@ configured IdentityServer to allow this access by [including it in the allowedScopes property](#define-client). Add the following to the *ConfigureServices* method in the API's *Program.cs* file: -```cs +``` builder.Services.AddAuthorization(options => { options.AddPolicy("ApiScope", policy => @@ -497,7 +498,7 @@ You can now enforce this policy at various levels, e.g.: Typically you set the policy for all controllers where they are mapped in *src/Api/Program.cs*: -```cs +``` app.MapControllers().RequireAuthorization("ApiScope"); ``` diff --git a/IdentityServer/v6/docs/content/quickstarts/2_interactive.md b/IdentityServer/v6/docs/content/quickstarts/2_interactive.md index d4880d10..47884d59 100644 --- a/IdentityServer/v6/docs/content/quickstarts/2_interactive.md +++ b/IdentityServer/v6/docs/content/quickstarts/2_interactive.md @@ -74,7 +74,7 @@ represent identity data like user id, name or email address rather than APIs. Add support for the standard *openid* (subject id) and *profile* (first name, last name, etc) scopes by declaring them in *src/IdentityServer/Config.cs*: -```cs +``` public static IEnumerable IdentityResources => new List { @@ -86,7 +86,7 @@ public static IEnumerable IdentityResources => Then register the identity resources in *src/IdentityServer/HostingExtensions.cs*: -```cs +``` builder.Services.AddIdentityServer() .AddInMemoryIdentityResources(Config.IdentityResources) .AddInMemoryApiScopes(Config.ApiScopes) @@ -105,7 +105,7 @@ Connect The sample UI also comes with an in-memory "user database". You can enable this by calling *AddTestUsers* in *src/IdentityServer/HostingExtensions.cs*: -```cs +``` builder.Services.AddIdentityServer() .AddInMemoryIdentityResources(Config.IdentityResources) .AddInMemoryApiScopes(Config.ApiScopes) @@ -130,7 +130,7 @@ are always interactive, we need to add some redirect URLs to our configuration. The *Clients* list in *src/IdentityServer/Config.cs* should look like this: -```cs +``` public static IEnumerable Clients => new List { @@ -201,7 +201,7 @@ dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConnect ### Configure Authentication Services Then add the following to *ConfigureServices* in *src/WebClient/Program.cs*: -```cs +``` using System.IdentityModel.Tokens.Jwt; // ... @@ -273,7 +273,7 @@ Now add *UseAuthentication* to the ASP.NET pipeline in *src/WebClient/Program.cs*. Also chain a call to *RequireAuthorization* onto *MapRazorPages* to disable anonymous access for the entire application. -```cs +``` app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); @@ -296,7 +296,7 @@ directory basis. Modify *src/WebClient/Pages/Index.cshtml* to display the claims of the user and the cookie properties: -```cs +``` @page @model IndexModel @@ -384,7 +384,7 @@ dotnet new page -n Signout Update the new page's model (*src/WebClient/Pages/Signout.cshtml.cs*) with the following code: -```cs +``` public class SignoutModel : PageModel { public IActionResult OnGet() @@ -426,7 +426,7 @@ userinfo endpoint by specifying scopes that the client application needs to access and setting the *GetClaimsFromUserInfoEndpoint* option. Add the following to *ConfigureServices* in *src/WebClient/Program.cs*: -```cs +``` .AddOpenIdConnect("oidc", options => { // ... @@ -459,7 +459,7 @@ To add more claims to the identity: get the associated *UserClaims*. For example, you could add an *IdentityResource* named "verification" which would include the *email* and *email_verified* claims. - ```csharp + ``` public static IEnumerable IdentityResources => new List { @@ -480,7 +480,7 @@ To add more claims to the identity: * Give the client access to the resource via the *AllowedScopes* property on the client configuration in *src/IdentityServer/Config.cs*. The string value in *AllowedScopes* must match the *Name* property of the resource. - ```csharp + ``` new Client { ClientId = "web", @@ -497,7 +497,7 @@ To add more claims to the identity: Connect handler configuration in *src/WebClient/Program.cs*, and add a [ClaimAction](https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.openidconnect.openidconnectoptions.claimactions?view=aspnetcore-6.0) to map the new claim returned from the userinfo endpoint onto a user claim. - ```csharp + ``` .AddOpenIdConnect("oidc", options => { // ... @@ -542,7 +542,7 @@ IdentityServer specific option. Add the following to *ConfigureServices* in *src/IdentityServer/HostingExtensions.cs*: -```cs +``` builder.Services.AddAuthentication() .AddGoogle("Google", options => { @@ -588,7 +588,7 @@ IdentityServer can be added as an additional external provider. Register and configure the services for the OpenId Connect handler in *src/IdentityServer/HostingExtensions.cs*: -```cs +``` builder.Services.AddAuthentication() .AddGoogle("Google", options => { /* ... */ }) .AddOpenIdConnect("oidc", "Demo IdentityServer", options => diff --git a/IdentityServer/v6/docs/content/quickstarts/3_api_access.md b/IdentityServer/v6/docs/content/quickstarts/3_api_access.md index 0e93282f..fcdc3391 100644 --- a/IdentityServer/v6/docs/content/quickstarts/3_api_access.md +++ b/IdentityServer/v6/docs/content/quickstarts/3_api_access.md @@ -41,7 +41,7 @@ The client configuration in IdentityServer requires two straightforward updates. 2. Enable support for refresh tokens by setting the *AllowOfflineAccess* flag. Update the *Client* in *src/IdentityServer/Config.cs* as follows: -```cs +``` new Client { ClientId = "web", @@ -71,7 +71,7 @@ Now configure the client to ask for access to api1 and for a refresh token by requesting the *api1* and *offline_access* scopes. This is done in the OpenID Connect handler configuration in *src/WebClient/Program.cs*: -```cs +``` builder.Services.AddAuthentication(options => { options.DefaultScheme = "Cookies"; @@ -120,7 +120,7 @@ dotnet new page -n CallApi ``` Update *src/WebClient/Pages/CallApi.cshtml.cs* as follows: -```cs +``` public class CallApiModel : PageModel { public string Json = string.Empty; diff --git a/IdentityServer/v6/docs/content/quickstarts/4_ef.md b/IdentityServer/v6/docs/content/quickstarts/4_ef.md index 2c83d34a..9b4f5ec1 100644 --- a/IdentityServer/v6/docs/content/quickstarts/4_ef.md +++ b/IdentityServer/v6/docs/content/quickstarts/4_ef.md @@ -76,7 +76,7 @@ To use these stores, replace the existing calls to *AddInMemoryClients*, *ConfigureServices* method in *src/IdentityServer/HostingExtensions.cs* with *AddConfigurationStore* and *AddOperationalStore*, like this: -```cs +``` public static WebApplication ConfigureServices(this WebApplicationBuilder builder) { var migrationsAssembly = typeof(Program).Assembly.GetName().Name; @@ -142,7 +142,7 @@ configuration, it shuts *IdentityServer* down by throwing a therefore stop *IdentityServer*. Since it is expected, you do not need to log it as a fatal error. Update the error logging code in *src/IdentityServer/Program.cs* as follows: -```csharp +``` catch (Exception ex) when ( // https://github.com/dotnet/runtime/issues/60600 ex.GetType().Name is not "StopTheHostException" @@ -191,7 +191,7 @@ maintenance strategy that is appropriate for your architecture. In *src/IdentityServer/HostingExtensions.cs*, add this method to initialize the database: -```cs +``` private static void InitializeDatabase(IApplicationBuilder app) { using (var serviceScope = app.ApplicationServices.GetService().CreateScope()) @@ -232,7 +232,7 @@ private static void InitializeDatabase(IApplicationBuilder app) Call *InitializeDatabase* from the *ConfigurePipeline* method: -```cs +``` public static WebApplication ConfigurePipeline(this WebApplication app) { app.UseSerilogRequestLogging(); diff --git a/IdentityServer/v6/docs/content/quickstarts/5_aspnetid.md b/IdentityServer/v6/docs/content/quickstarts/5_aspnetid.md index 829e060d..f82a78ef 100644 --- a/IdentityServer/v6/docs/content/quickstarts/5_aspnetid.md +++ b/IdentityServer/v6/docs/content/quickstarts/5_aspnetid.md @@ -106,7 +106,7 @@ To keep the same clients and API working as the prior quickstarts, we need to copy over the configuration data from the old IdentityServer project into this one. Do that now, and afterwards *Config.cs* should look like this: -```cs +``` public static class Config { public static IEnumerable IdentityResources => @@ -217,7 +217,7 @@ Next you will add a custom property to your user model and include it as a claim when the appropriate Identity Resource is requested. First, add a *FavoriteColor* property to the *ApplicationUser* class. -```csharp +``` public class ApplicationUser : IdentityUser { public string FavoriteColor { get; set; } @@ -226,7 +226,7 @@ public class ApplicationUser : IdentityUser Then, set the FavoriteColor of one of your test users in *SeedData.cs* -```csharp +``` alice = new ApplicationUser { UserName = "alice", @@ -240,7 +240,7 @@ In the same file, add code to recreate the database when you re-seed the data, by calling *EnsureDeleted* just before *Migrate*: -```csharp +``` var context = scope.ServiceProvider.GetService(); context.Database.EnsureDeleted(); context.Database.Migrate(); @@ -270,7 +270,7 @@ data as a source of claims data. [See here]({{< ref service. Create a new class called *CustomProfileService* and add the following code to it: -```csharp +``` using Duende.IdentityServer.AspNetIdentity; using Duende.IdentityServer.Models; using IdentityServerAspNetIdentity.Models; @@ -301,7 +301,7 @@ namespace IdentityServerAspNetIdentity ``` Register the *CustomProfileService* in *HostingExtensions.cs*: -```csharp +``` builder.Services .AddIdentityServer(options => { @@ -320,7 +320,7 @@ favorite_color, and include that claim in your client's configuration. Add a new *IdentityResource* in *src/IdentityServerAspNetIdentity/Config.cs* that will map the color scope onto the favorite_color claim type: -```csharp +``` public static IEnumerable IdentityResources => new IdentityResource[] { @@ -331,7 +331,7 @@ public static IEnumerable IdentityResources => ``` Allow the web client to request the color scope (also in *Config.cs*): -```csharp +``` new Client { ClientId = "web", @@ -351,7 +351,7 @@ Finally, update the *WebClient* project so that it will request the color scope. In its *src/WebClient/Program.cs* file, add the color scope to the requested scopes, and add a claim action to map the favorite_color into the principal: -```csharp +``` .AddOpenIdConnect("oidc", options => { // ... diff --git a/IdentityServer/v6/docs/content/quickstarts/7_blazor.md b/IdentityServer/v6/docs/content/quickstarts/7_blazor.md index a75bbd4c..2922ee8c 100644 --- a/IdentityServer/v6/docs/content/quickstarts/7_blazor.md +++ b/IdentityServer/v6/docs/content/quickstarts/7_blazor.md @@ -37,7 +37,7 @@ The BFF services provide the logic to invoke the authentication plumbing from th Add the following snippet to your *Program.cs* above the call to *builder.Build();* -```cs +``` builder.Services.AddBff(); builder.Services.AddAuthentication(options => @@ -74,7 +74,7 @@ builder.Services.AddAuthentication(options => The last step is to add the required middleware for authentication, authorization and BFF session management. Add the following snippet after the call to *UseRouting*: -```cs +``` app.UseAuthentication(); app.UseBff(); app.UseAuthorization(); @@ -99,7 +99,7 @@ A couple of steps are necessary to add the security and identity plumbing to a B **b)** Add a using statement to *_Imports.razor* to bring the above package in scope: -```cs +``` @using Microsoft.AspNetCore.Components.Authorization ``` @@ -166,7 +166,7 @@ The BFF library has a server-side component that allows querying the current aut Add a file with the following content: -```cs +``` using System.Net; using System.Net.Http.Json; using System.Security.Claims; @@ -255,7 +255,7 @@ public class BffAuthenticationStateProvider ..and register it in the client's *Program.cs*: -```cs +``` builder.Services.AddAuthorizationCore(); builder.Services.AddScoped(); ``` @@ -271,7 +271,7 @@ This is due to the antiforgery protection that is applied automatically to the m This can be easily accomplished by a delegating handler that can be plugged into the default HTTP client used by the Blazor frontend. Let's first add the handler: -```cs +``` public class AntiforgeryHandler : DelegatingHandler { protected override Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) @@ -284,7 +284,7 @@ public class AntiforgeryHandler : DelegatingHandler ..and register it in the client's *Program.cs* (overriding the standard HTTP client configuration; requires package Microsoft.Extensions.Http): -```cs +``` // HTTP client configuration builder.Services.AddTransient(); @@ -326,7 +326,7 @@ The standard Blazor template contains an API endpoint (*WeatherForecastControlle The standard way in ASP.NET Core would be to add an authorization requirement to the endpoint, either on the controller/action or via the endpoint routing, e.g.: -```cs +``` app.MapControllers() .RequireAuthorization(); ``` @@ -341,7 +341,7 @@ This happens because the ASP.NET Core authentication plumbing is triggering a re This is one of the features of the BFF middleware, but you need to mark the endpoint as a BFF API endpoint for that to take effect: -```cs +``` app.MapControllers() .RequireAuthorization() .AsBffApiEndpoint(); @@ -368,7 +368,7 @@ In essence a BFF client is "just" a normal authorization code flow client: Below is a typical code snippet for the client definition: -```cs +``` var bffClient = new Client { ClientId = "bff", diff --git a/IdentityServer/v6/docs/content/quickstarts/js_clients/js_with_backend.md b/IdentityServer/v6/docs/content/quickstarts/js_clients/js_with_backend.md index fc44349d..41ae885e 100644 --- a/IdentityServer/v6/docs/content/quickstarts/js_clients/js_with_backend.md +++ b/IdentityServer/v6/docs/content/quickstarts/js_clients/js_with_backend.md @@ -89,7 +89,7 @@ WebClient did in the prior [web application quickstart]({{ { endpoints.MapBffManagementEndpoints(); diff --git a/IdentityServer/v6/docs/content/quickstarts/js_clients/js_without_backend.md b/IdentityServer/v6/docs/content/quickstarts/js_clients/js_without_backend.md index b48b4c45..8ea6d944 100644 --- a/IdentityServer/v6/docs/content/quickstarts/js_clients/js_without_backend.md +++ b/IdentityServer/v6/docs/content/quickstarts/js_clients/js_without_backend.md @@ -75,7 +75,7 @@ application. The static file middleware is designed to do this. Register the static file middleware in *src/JavaScriptClient/Program.cs*. The entire file should look like this: -```cs +``` var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); @@ -306,7 +306,7 @@ In the IdentityServer project locate the client configuration in *src/IdentityServer/Config.cs*. Add a new *Client* to the list for your new JavaScript application. It should have the configuration listed below: -```cs +``` // JavaScript Client new Client { @@ -339,7 +339,7 @@ One last bit of configuration that is necessary is to configure CORS in the Add the CORS services to the dependency injection system in *src/Api/Program.cs*: -```cs +``` builder.Services.AddCors(options => { // this defines a CORS policy called "default" @@ -355,7 +355,7 @@ builder.Services.AddCors(options => Then add the CORS middleware to the pipeline in *src/Api/Program.cs*. It should come before the call to *UseAuthentication*. -```cs +``` app.UseHttpsRedirection(); app.UseCors("default"); diff --git a/IdentityServer/v6/docs/content/reference/di.md b/IdentityServer/v6/docs/content/reference/di.md index 7a55d6a0..03c569a8 100644 --- a/IdentityServer/v6/docs/content/reference/di.md +++ b/IdentityServer/v6/docs/content/reference/di.md @@ -6,7 +6,7 @@ weight: 20 *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. -```cs +``` public void ConfigureServices(IServiceCollection services) { var builder = services.AddIdentityServer(); diff --git a/IdentityServer/v6/docs/content/reference/efoptions/configuration.md b/IdentityServer/v6/docs/content/reference/efoptions/configuration.md index 1435571c..cf88f121 100644 --- a/IdentityServer/v6/docs/content/reference/efoptions/configuration.md +++ b/IdentityServer/v6/docs/content/reference/efoptions/configuration.md @@ -10,7 +10,7 @@ These options are configurable when using the Entity Framework Core for the [con You set the options at startup time in your *AddConfigurationStore* method: -```cs +``` var builder = services.AddIdentityServer() .AddConfigurationStore(options => { diff --git a/IdentityServer/v6/docs/content/reference/efoptions/operational.md b/IdentityServer/v6/docs/content/reference/efoptions/operational.md index 83a6c90d..5dc7ba43 100644 --- a/IdentityServer/v6/docs/content/reference/efoptions/operational.md +++ b/IdentityServer/v6/docs/content/reference/efoptions/operational.md @@ -9,7 +9,7 @@ These options are configurable when using the Entity Framework Core for the [ope You set the options at startup time in your *AddOperationalStore* method: -```cs +``` var builder = services.AddIdentityServer() .AddOperationalStore(options => { diff --git a/IdentityServer/v6/docs/content/reference/endpoints/authorize.md b/IdentityServer/v6/docs/content/reference/endpoints/authorize.md index e958e16b..f9e3d683 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/authorize.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/authorize.md @@ -135,7 +135,7 @@ GET /connect/authorize? ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically create authorize request URLs from .NET code. -```cs +``` var ru = new RequestUrl("https://demo.duendesoftware.com/connect/authorize"); var url = ru.CreateAuthorizeUrl( diff --git a/IdentityServer/v6/docs/content/reference/endpoints/ciba.md b/IdentityServer/v6/docs/content/reference/endpoints/ciba.md index 4ebb9b27..fa2834fa 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/ciba.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/ciba.md @@ -97,7 +97,7 @@ Cache-Control: no-store ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); @@ -114,7 +114,7 @@ var cibaResponse = await client.RequestBackchannelAuthenticationAsync(new Backch And with a successful response, it can be used to poll the token endpoint: -```cs +``` while (true) { var response = await client.RequestBackchannelAuthenticationTokenAsync(new BackchannelAuthenticationTokenRequest diff --git a/IdentityServer/v6/docs/content/reference/endpoints/device_authorization.md b/IdentityServer/v6/docs/content/reference/endpoints/device_authorization.md index d16229b3..269e7051 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/device_authorization.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/device_authorization.md @@ -30,7 +30,7 @@ POST /connect/deviceauthorization ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/reference/endpoints/discovery.md b/IdentityServer/v6/docs/content/reference/endpoints/discovery.md index 985fa06c..6396dc7b 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/discovery.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/discovery.md @@ -13,7 +13,7 @@ The discovery endpoint is available via */.well-known/openid-configuration* rela ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` var client = new HttpClient(); var disco = await client.GetDiscoveryDocumentAsync("https://demo.duendesoftware.com"); diff --git a/IdentityServer/v6/docs/content/reference/endpoints/end_session.md b/IdentityServer/v6/docs/content/reference/endpoints/end_session.md index 037d1740..e791c3f0 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/end_session.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/end_session.md @@ -37,7 +37,7 @@ The URL for the end session endpoint is available via discovery. ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically create end sessions request URLs from .NET code. -```cs +``` var ru = new RequestUrl("https://demo.duendesoftware.com/connect/end_session"); var url = ru.CreateEndSessionUrl( diff --git a/IdentityServer/v6/docs/content/reference/endpoints/introspection.md b/IdentityServer/v6/docs/content/reference/endpoints/introspection.md index 8a19faf3..710e27dd 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/introspection.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/introspection.md @@ -38,7 +38,7 @@ An invalid request will return a 400, an unauthorized request 401. ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/reference/endpoints/revocation.md b/IdentityServer/v6/docs/content/reference/endpoints/revocation.md index cf809702..f862c15d 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/revocation.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/revocation.md @@ -27,7 +27,7 @@ token=...&token_type_hint=refresh_token ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/reference/endpoints/token.md b/IdentityServer/v6/docs/content/reference/endpoints/token.md index a1c887f2..bff20c4a 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/token.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/token.md @@ -92,7 +92,7 @@ CONTENT-TYPE application/x-www-form-urlencoded ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/reference/endpoints/userinfo.md b/IdentityServer/v6/docs/content/reference/endpoints/userinfo.md index a9cbf160..b4480557 100644 --- a/IdentityServer/v6/docs/content/reference/endpoints/userinfo.md +++ b/IdentityServer/v6/docs/content/reference/endpoints/userinfo.md @@ -29,7 +29,7 @@ Content-Type: application/json ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/reference/models/api_resource.md b/IdentityServer/v6/docs/content/reference/models/api_resource.md index b42e5c65..0648dfa0 100644 --- a/IdentityServer/v6/docs/content/reference/models/api_resource.md +++ b/IdentityServer/v6/docs/content/reference/models/api_resource.md @@ -79,6 +79,6 @@ The *AddInMemoryApiResource* extensions method also supports adding API resource Then pass the configuration section to the *AddInMemoryApiResource* method: -```cs +``` builder.AddInMemoryApiResources(configuration.GetSection("IdentityServer:ApiResources")) ``` diff --git a/IdentityServer/v6/docs/content/reference/models/api_scope.md b/IdentityServer/v6/docs/content/reference/models/api_scope.md index dfc8e72f..597a766b 100644 --- a/IdentityServer/v6/docs/content/reference/models/api_scope.md +++ b/IdentityServer/v6/docs/content/reference/models/api_scope.md @@ -63,6 +63,6 @@ The *AddInMemoryApiResource* extension method also supports adding clients from Then pass the configuration section to the *AddInMemoryApiScopes* method: -```cs +``` builder.AddInMemoryApiScopes(configuration.GetSection("IdentityServer:ApiScopes")) ``` \ No newline at end of file diff --git a/IdentityServer/v6/docs/content/reference/models/client.md b/IdentityServer/v6/docs/content/reference/models/client.md index 2e344195..a86f2def 100644 --- a/IdentityServer/v6/docs/content/reference/models/client.md +++ b/IdentityServer/v6/docs/content/reference/models/client.md @@ -10,7 +10,7 @@ weight: 35 The *Client* class models an OpenID Connect or OAuth 2.0 client - e.g. a native application, a web application or a JS-based application. -```cs +``` public static IEnumerable Get() { return new List diff --git a/IdentityServer/v6/docs/content/reference/models/grant_validation_result.md b/IdentityServer/v6/docs/content/reference/models/grant_validation_result.md index c683bd47..dfa23abe 100644 --- a/IdentityServer/v6/docs/content/reference/models/grant_validation_result.md +++ b/IdentityServer/v6/docs/content/reference/models/grant_validation_result.md @@ -10,7 +10,7 @@ The *GrantValidationResult* class models the outcome of grant validation for [ex It models either a successful validation result with claims (e.g. subject ID) or an invalid result with an error code and message, e.g.: -```cs +``` public class ExtensionGrantValidator : IExtensionGrantValidator { public Task ValidateAsync(ExtensionGrantValidationContext context) @@ -39,7 +39,7 @@ public class ExtensionGrantValidator : IExtensionGrantValidator It also allows passing additional custom values that will be included in the token response, e.g.: -```cs +``` context.Result = new GrantValidationResult( subject: "818727", authenticationMethod: "custom", diff --git a/IdentityServer/v6/docs/content/reference/models/identity_resource.md b/IdentityServer/v6/docs/content/reference/models/identity_resource.md index 37448797..389fadd7 100644 --- a/IdentityServer/v6/docs/content/reference/models/identity_resource.md +++ b/IdentityServer/v6/docs/content/reference/models/identity_resource.md @@ -9,7 +9,7 @@ weight: 20 This class models an identity resource. -```cs +``` public static readonly IEnumerable IdentityResources = new[] { diff --git a/IdentityServer/v6/docs/content/reference/models/secrets.md b/IdentityServer/v6/docs/content/reference/models/secrets.md index b1280aeb..0078ba86 100644 --- a/IdentityServer/v6/docs/content/reference/models/secrets.md +++ b/IdentityServer/v6/docs/content/reference/models/secrets.md @@ -8,7 +8,7 @@ weight: 70 Parses a secret from the raw HTTP request. -```cs +``` public interface ISecretParser { /// @@ -39,7 +39,7 @@ public interface ISecretParser Represents a parsed secret. -```cs +``` /// /// Represents a secret extracted from the HttpContext /// @@ -85,7 +85,7 @@ The parsed secret is forwarded to the registered secret validator. The validator Validates a parsed secret. -```cs +``` public interface ISecretValidator { /// Validates a secret diff --git a/IdentityServer/v6/docs/content/reference/options.md b/IdentityServer/v6/docs/content/reference/options.md index 72475200..9fb8d71d 100644 --- a/IdentityServer/v6/docs/content/reference/options.md +++ b/IdentityServer/v6/docs/content/reference/options.md @@ -9,7 +9,7 @@ The *IdentityServerOptions* is the central place to configure fundamental settin You set the options when registering IdentityServer at startup time, using a lambda expression in the AddIdentityServer method: -```cs +``` var builder = services.AddIdentityServer(options => { // configure options here.. @@ -225,7 +225,7 @@ If you want to take full control over the rendering of the discovery and jwks do * ***CustomEntries*** Adds custom elements to the discovery document. For example: -```cs +``` var builder = services.AddIdentityServer(options => { options.Discovery.CustomEntries.Add("my_setting", "foo"); @@ -241,7 +241,7 @@ var builder = services.AddIdentityServer(options => * ***ExpandRelativePathsInCustomEntries*** Expands paths in custom entries that begin with "~/" into absolute paths below the IdentityServer base address. Defaults to true. In the following example, if IdentityServer's base address is *https://localhost:5001*, then *my_custom_endpoint*'s value will be expanded to *https://localhost:5001/custom*. -```cs +``` options.Discovery.CustomEntries.Add("my_custom_endpoint", "~/custom"); ``` @@ -572,7 +572,7 @@ OAuth device flow settings. Available on the *DeviceFlow* property of the *Ident ## Mutual TLS [Mutual TLS]({{< ref "/tokens/authentication/mtls" >}}) settings. Available on the *MutualTls* property of the *IdentityServerOptions* object. -```cs +``` var builder = services.AddIdentityServer(options => { options.MutualTls.Enabled = true; diff --git a/IdentityServer/v6/docs/content/reference/services/persisted_grant_service.md b/IdentityServer/v6/docs/content/reference/services/persisted_grant_service.md index af97a570..45e151cf 100644 --- a/IdentityServer/v6/docs/content/reference/services/persisted_grant_service.md +++ b/IdentityServer/v6/docs/content/reference/services/persisted_grant_service.md @@ -7,7 +7,7 @@ weight: 43 Provides access to a user's grants. -```cs +``` /// /// Implements persisted grant logic /// @@ -33,7 +33,7 @@ Provides access to a user's grants. ### Grant -```cs +``` /// /// Models a grant the user has given. /// diff --git a/IdentityServer/v6/docs/content/reference/services/profile_service.md b/IdentityServer/v6/docs/content/reference/services/profile_service.md index 429eca64..51fbd7ad 100644 --- a/IdentityServer/v6/docs/content/reference/services/profile_service.md +++ b/IdentityServer/v6/docs/content/reference/services/profile_service.md @@ -8,7 +8,7 @@ weight: 40 Encapsulates retrieval of user claims from a data source of your choice. See [here]({{< ref "/samples/ui#custom-profile-service" >}}) for a sample. -```cs +``` /// /// This interface allows IdentityServer to connect to your user and profile store. /// diff --git a/IdentityServer/v6/docs/content/reference/services/refresh_token_service.md b/IdentityServer/v6/docs/content/reference/services/refresh_token_service.md index d0b64b9c..9a0eef9c 100644 --- a/IdentityServer/v6/docs/content/reference/services/refresh_token_service.md +++ b/IdentityServer/v6/docs/content/reference/services/refresh_token_service.md @@ -7,7 +7,7 @@ weight: 50 All refresh token handling is implemented in the *DefaultRefreshTokenService* (which is the default implementation of the *IRefreshTokenService* interface): -```cs +``` public interface IRefreshTokenService { /// diff --git a/IdentityServer/v6/docs/content/reference/services/session_management_service.md b/IdentityServer/v6/docs/content/reference/services/session_management_service.md index cf6a2cc7..28cefe42 100644 --- a/IdentityServer/v6/docs/content/reference/services/session_management_service.md +++ b/IdentityServer/v6/docs/content/reference/services/session_management_service.md @@ -7,7 +7,7 @@ weight: 57 When using [server-side sessions]({{}}), the *ISessionManagementService* provides an administrative feature to query those sessions and terminate those sessions (including associated tokens, consents, and triggering back-channel logout to the clients). -```cs +``` /// /// Session management service /// @@ -27,7 +27,7 @@ public interface ISessionManagementService *QuerySessionsAsync* allows for returning paged results of *UserSession* data based on the optional *SessionQuery* filter. -```cs +``` /// /// Results from querying user sessions from session management service. /// @@ -77,7 +77,7 @@ public class UserSession *RemoveSessionsAsync* will terminate server-side sessions based on *SubjectId* and/or *SessionId*, and allow for fine-grained flags for what to revoke and/or notify. -```cs +``` /// /// Models the information to remove a user's session data. /// diff --git a/IdentityServer/v6/docs/content/reference/stores/backchannel_auth_request_store.md b/IdentityServer/v6/docs/content/reference/stores/backchannel_auth_request_store.md index c9ae8d49..34234ebb 100644 --- a/IdentityServer/v6/docs/content/reference/stores/backchannel_auth_request_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/backchannel_auth_request_store.md @@ -7,7 +7,7 @@ weight: 80 Used to store backchannel login requests (for [CIBA]({{< ref "/ui/ciba">}})). -```cs +``` /// /// Interface for the backchannel authentication request store /// @@ -47,7 +47,7 @@ Used to store backchannel login requests (for [CIBA]({{< ref "/ui/ciba">}})). #### BackChannelAuthenticationRequest -```cs +``` /// /// Models a backchannel authentication request. /// diff --git a/IdentityServer/v6/docs/content/reference/stores/client_store.md b/IdentityServer/v6/docs/content/reference/stores/client_store.md index 32f71331..d540b337 100644 --- a/IdentityServer/v6/docs/content/reference/stores/client_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/client_store.md @@ -7,7 +7,7 @@ weight: 36 Used to dynamically load client configuration. -```cs +``` /// /// Retrieval of client configuration /// diff --git a/IdentityServer/v6/docs/content/reference/stores/cors_policy_service.md b/IdentityServer/v6/docs/content/reference/stores/cors_policy_service.md index 8d28cc7e..71087d39 100644 --- a/IdentityServer/v6/docs/content/reference/stores/cors_policy_service.md +++ b/IdentityServer/v6/docs/content/reference/stores/cors_policy_service.md @@ -7,7 +7,7 @@ weight: 36 Used to determine if CORS requests are allowed to certain protocol endpoints. -```cs +``` /// /// Service that determines if CORS is allowed. /// diff --git a/IdentityServer/v6/docs/content/reference/stores/device_flow_store.md b/IdentityServer/v6/docs/content/reference/stores/device_flow_store.md index 482b6ab5..f016a5b4 100644 --- a/IdentityServer/v6/docs/content/reference/stores/device_flow_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/device_flow_store.md @@ -7,7 +7,7 @@ weight: 43 Models storage of grants for the device flow. -```cs +``` /// /// Interface for the device flow store /// @@ -52,7 +52,7 @@ Models storage of grants for the device flow. #### DeviceCode -```cs +``` /// /// Represents data needed for device flow. /// diff --git a/IdentityServer/v6/docs/content/reference/stores/idp_store.md b/IdentityServer/v6/docs/content/reference/stores/idp_store.md index 302dbb59..57bc1c91 100644 --- a/IdentityServer/v6/docs/content/reference/stores/idp_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/idp_store.md @@ -7,7 +7,7 @@ weight: 36 Used to dynamically load [identity provider configuration]({{}}). -```cs +``` /// /// Interface to model storage of identity providers. /// diff --git a/IdentityServer/v6/docs/content/reference/stores/persisted_grant_store.md b/IdentityServer/v6/docs/content/reference/stores/persisted_grant_store.md index 063bb261..b41b69c2 100644 --- a/IdentityServer/v6/docs/content/reference/stores/persisted_grant_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/persisted_grant_store.md @@ -145,7 +145,7 @@ one-time use semantics are appropriate for the grant. #### PersistedGrantFilter -```cs +``` /// /// Represents a filter used when accessing the persisted grants store. /// Setting multiple properties is interpreted as a logical 'AND' to further filter the query. @@ -189,7 +189,7 @@ one-time use semantics are appropriate for the grant. The types of persisted grants are defined by the `IdentityServerConstants.PersistedGrantTypes` constants: -```cs +``` public static class PersistedGrantTypes { public const string AuthorizationCode = "authorization_code"; diff --git a/IdentityServer/v6/docs/content/reference/stores/resource_store.md b/IdentityServer/v6/docs/content/reference/stores/resource_store.md index f054e840..05be26fa 100644 --- a/IdentityServer/v6/docs/content/reference/stores/resource_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/resource_store.md @@ -7,7 +7,7 @@ weight: 32 Used to dynamically load resource configuration. -```cs +``` /// /// Resource retrieval /// diff --git a/IdentityServer/v6/docs/content/reference/stores/server_side_sessions.md b/IdentityServer/v6/docs/content/reference/stores/server_side_sessions.md index 19ece14d..29f810cf 100644 --- a/IdentityServer/v6/docs/content/reference/stores/server_side_sessions.md +++ b/IdentityServer/v6/docs/content/reference/stores/server_side_sessions.md @@ -8,7 +8,7 @@ weight: 100 Used to persist users' authentication session data when using the [server-side sessions feature]({{}}). -```cs +``` /// /// User session store /// @@ -55,7 +55,7 @@ public interface IServerSideSessionStore #### ServerSideSession -```cs +``` /// /// A user session /// @@ -114,7 +114,7 @@ The *Ticket* property contains a copy of all of the values (and more) and is con #### SessionFilter -```cs +``` /// /// Filter to query user sessions /// @@ -135,7 +135,7 @@ public class SessionFilter #### SessionQuery -```cs +``` /// /// Filter to query all user sessions /// @@ -175,7 +175,7 @@ public class SessionQuery #### QueryResult -```cs +``` /// /// Query result for paged data /// diff --git a/IdentityServer/v6/docs/content/reference/stores/signing_key_store.md b/IdentityServer/v6/docs/content/reference/stores/signing_key_store.md index 9d14f950..cf10400e 100644 --- a/IdentityServer/v6/docs/content/reference/stores/signing_key_store.md +++ b/IdentityServer/v6/docs/content/reference/stores/signing_key_store.md @@ -7,7 +7,7 @@ weight: 90 Used to dynamically load client configuration. -```cs +``` /// /// Interface to model storage of serialized keys. /// @@ -37,7 +37,7 @@ Used to dynamically load client configuration. #### SerializedKey -```cs +``` /// /// Serialized key. /// diff --git a/IdentityServer/v6/docs/content/reference/validators/custom_authorize_request_validator.md b/IdentityServer/v6/docs/content/reference/validators/custom_authorize_request_validator.md index 038a2cc6..8be1c2ff 100644 --- a/IdentityServer/v6/docs/content/reference/validators/custom_authorize_request_validator.md +++ b/IdentityServer/v6/docs/content/reference/validators/custom_authorize_request_validator.md @@ -7,7 +7,7 @@ weight: 10 Allows running custom code as part of the authorization issuance pipeline at the authorization endpoint. -```cs +``` /// /// Allows inserting custom validation logic into authorize requests /// diff --git a/IdentityServer/v6/docs/content/reference/validators/custom_token_request_validator.md b/IdentityServer/v6/docs/content/reference/validators/custom_token_request_validator.md index 9a32f3b2..f43a4436 100644 --- a/IdentityServer/v6/docs/content/reference/validators/custom_token_request_validator.md +++ b/IdentityServer/v6/docs/content/reference/validators/custom_token_request_validator.md @@ -7,7 +7,7 @@ weight: 20 Allows running custom code as part of the token issuance pipeline at the token endpoint. -```cs +``` /// /// Allows inserting custom validation logic into token requests /// diff --git a/IdentityServer/v6/docs/content/reference/validators/extension_grant_validator.md b/IdentityServer/v6/docs/content/reference/validators/extension_grant_validator.md index b5f70b39..d667e203 100644 --- a/IdentityServer/v6/docs/content/reference/validators/extension_grant_validator.md +++ b/IdentityServer/v6/docs/content/reference/validators/extension_grant_validator.md @@ -7,7 +7,7 @@ weight: 80 Use an implementation of this interface to handle [extension grants]({{< ref "/tokens/extension_grants" >}}). -```cs +``` public interface IExtensionGrantValidator { /// @@ -37,6 +37,6 @@ public interface IExtensionGrantValidator The instance of the extension grant validator gets registered with: -```cs +``` builder.AddExtensionGrantValidator(); ``` \ No newline at end of file diff --git a/IdentityServer/v6/docs/content/tokens/authentication/jwt.md b/IdentityServer/v6/docs/content/tokens/authentication/jwt.md index 7be3623e..ce3036cf 100644 --- a/IdentityServer/v6/docs/content/tokens/authentication/jwt.md +++ b/IdentityServer/v6/docs/content/tokens/authentication/jwt.md @@ -60,7 +60,7 @@ Content-type: application/x-www-form-urlencoded ### .NET client library You can use the [Microsoft JWT library](https://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt/) to create JSON Web Tokens. -```cs +``` private static string CreateClientToken(SigningCredentials credential, string clientId, string tokenEndpoint) { var now = DateTime.UtcNow; @@ -86,7 +86,7 @@ private static string CreateClientToken(SigningCredentials credential, string cl ..and the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; static async Task RequestTokenAsync(SigningCredentials credential) @@ -122,7 +122,7 @@ The OpenID Connect authentication handler in ASP.NET Core allows for replacing a This is accomplished by handling the various events on the handler. We recommend to encapsulate the event handler in a separate type. This makes it easier to consume services from DI: -```cs +``` public void ConfigureServices(IServiceCollection services) { // some details omitted @@ -144,7 +144,7 @@ public void ConfigureServices(IServiceCollection services) In your event handler you can inject code before the handler redeems the code: -```cs +``` public class OidcEvents : OpenIdConnectEvents { private readonly AssertionService _assertionService; diff --git a/IdentityServer/v6/docs/content/tokens/authentication/mtls.md b/IdentityServer/v6/docs/content/tokens/authentication/mtls.md index c1844e55..77845236 100644 --- a/IdentityServer/v6/docs/content/tokens/authentication/mtls.md +++ b/IdentityServer/v6/docs/content/tokens/authentication/mtls.md @@ -8,7 +8,7 @@ Clients can use an X.509 client certificate as an authentication mechanism to en For this you need to associate a client certificate with a client in your IdentityServer and enable MTLS support on the options. -```cs +``` var builder = service.AddIdentityServer(options => { options.MutualTls.Enabled = true; @@ -17,7 +17,7 @@ var builder = service.AddIdentityServer(options => Use the [DI extensions methods]({{< ref "/reference/di" >}}) to add the services to DI which contain a default implementation to do that either thumbprint or common-name based: -```cs +``` builder.AddMutualTlsSecretValidators(); ``` @@ -26,7 +26,7 @@ or *SecretTypes.X509CertificateThumbprint* (for self-issued certificates) to the For example:: -```cs +``` new Client { ClientId = "mtls.client", @@ -57,7 +57,7 @@ class provides a convenient mechanism to add a client certificate to outgoing re Use such a handler with *HttpClient* to perform the client certificate authentication handshake at the TLS channel. The following snippet is using [IdentityModel](https://identitymodel.readthedocs.io) to read the discovery document and request a token: -```cs +``` static async Task RequestTokenAsync() { var handler = new SocketsHttpHandler(); diff --git a/IdentityServer/v6/docs/content/tokens/authentication/overview.md b/IdentityServer/v6/docs/content/tokens/authentication/overview.md index 3568ce08..e74fb009 100644 --- a/IdentityServer/v6/docs/content/tokens/authentication/overview.md +++ b/IdentityServer/v6/docs/content/tokens/authentication/overview.md @@ -18,7 +18,7 @@ All information in this section also applies to [API secrets]({{< ref "/referenc ## Assigning secrets A client secret is abstracted by the *Secret* class. It provides properties for setting the value and type as well as a description and expiration date. -```cs +``` var secret = new Secret { Value = "foo", @@ -31,7 +31,7 @@ var secret = new Secret You can assign multiple secrets to a client to enable roll-over scenarios, e.g.: -```cs +``` var primary = new Secret("foo"); var secondary = new Secret("bar"); diff --git a/IdentityServer/v6/docs/content/tokens/authentication/shared_secret.md b/IdentityServer/v6/docs/content/tokens/authentication/shared_secret.md index 537cae8b..192cbb49 100644 --- a/IdentityServer/v6/docs/content/tokens/authentication/shared_secret.md +++ b/IdentityServer/v6/docs/content/tokens/authentication/shared_secret.md @@ -14,7 +14,7 @@ From a security point of view they have some shortcomings The following creates a shared secret: -```cs +``` // loadSecret is responsible for loading a SHA256 or SHA512 hash of a good, // high-entropy secret from a secure storage location var hash = loadSecretHash(); @@ -32,7 +32,7 @@ when prototyping or during demos to get started quickly. However, the clear text of secrets used in production should never be written down in your source code. Anyone with access to the repository can see the secret. -```cs +``` var compromisedSecret = new Secret("just for demos, not prod!".Sha256()); ``` @@ -70,7 +70,7 @@ Authorization: Basic xxxxx ## .NET client library You can use the [IdentityModel](https://identitymodel.readthedocs.io) client library to programmatically interact with the protocol endpoint from .NET code. -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/tokens/cors.md b/IdentityServer/v6/docs/content/tokens/cors.md index e68c573d..46855f0d 100644 --- a/IdentityServer/v6/docs/content/tokens/cors.md +++ b/IdentityServer/v6/docs/content/tokens/cors.md @@ -36,7 +36,7 @@ This would be configured as a singleton in DI, and hard-coded with its *AllowedO For example, in *ConfigureServices*: -```cs +``` services.AddSingleton((container) => { var logger = container.GetRequiredService>(); diff --git a/IdentityServer/v6/docs/content/tokens/dynamic_validation.md b/IdentityServer/v6/docs/content/tokens/dynamic_validation.md index 3c0abb07..a15b0267 100644 --- a/IdentityServer/v6/docs/content/tokens/dynamic_validation.md +++ b/IdentityServer/v6/docs/content/tokens/dynamic_validation.md @@ -19,7 +19,7 @@ This allows you to The following example emits additional claims and changes the token lifetime on-the-fly based on a granted scope. -```cs +``` public class TransactionScopeTokenRequestValidator : ICustomTokenRequestValidator { public Task ValidateAsync(CustomTokenRequestValidationContext context) @@ -48,6 +48,6 @@ public class TransactionScopeTokenRequestValidator : ICustomTokenRequestValidato You can register your implementation like this: -```cs +``` builder.AddCustomTokenRequestValidator(); ``` diff --git a/IdentityServer/v6/docs/content/tokens/extension_grants/token_exchange.md b/IdentityServer/v6/docs/content/tokens/extension_grants/token_exchange.md index c9093755..5f261110 100644 --- a/IdentityServer/v6/docs/content/tokens/extension_grants/token_exchange.md +++ b/IdentityServer/v6/docs/content/tokens/extension_grants/token_exchange.md @@ -19,7 +19,7 @@ Some of the logic is boilerplate: Here's a simple implementation of the above steps: -```cs +``` public class TokenExchangeGrantValidator : IExtensionGrantValidator { private readonly ITokenValidator _validator; @@ -81,13 +81,13 @@ public class TokenExchangeGrantValidator : IExtensionGrantValidator You then register your grant validator with DI: -```cs +``` builder.AddExtensionGrantValidator(); ``` And configure your client to be able to use it: -```cs +``` client.AllowedGrantTypes = { OidcConstants.GrantTypes.TokenExchange }; ``` @@ -116,7 +116,7 @@ In the impersonation use case, API 1 doing the token exchange becomes "invisible Add the following code to the above validator to create an impersonation response: -```cs +``` // set token client_id to original id context.Request.ClientId = clientId; @@ -146,7 +146,7 @@ For API 2 it still looks like that the front-end is making the call, but by insp The following code adds the *act* claim to the response: -```cs +``` // set token client_id to original id context.Request.ClientId = clientId; @@ -168,7 +168,7 @@ context.Result = new GrantValidationResult( To emit the *act* claim into outgoing tokens, your [profile service]({{< ref "/reference/services/profile_service" >}}) must know about it. The following simple profile service emits the *act* claim if the token request is in the context of a token exchange operation: -```cs +``` public class ProfileService : IProfileService { public override async Task GetProfileDataAsync(ProfileDataRequestContext context) diff --git a/IdentityServer/v6/docs/content/tokens/internal.md b/IdentityServer/v6/docs/content/tokens/internal.md index d403218b..5eb29b93 100644 --- a/IdentityServer/v6/docs/content/tokens/internal.md +++ b/IdentityServer/v6/docs/content/tokens/internal.md @@ -17,7 +17,7 @@ for IdentityServer. To use it, inject it into your code, e.g. a controller:: The *IssueJwtAsync* method allows creating JWT tokens using the IdentityServer token creation engine. The *IssueClientJwtAsync* is an easier version of that for creating tokens for server-to-server communication (e.g. when you have to call an IdentityServer protected API from your code): -```cs +``` public async Task MyAction() { var token = await _tools.IssueClientJwtAsync( diff --git a/IdentityServer/v6/docs/content/tokens/jar.md b/IdentityServer/v6/docs/content/tokens/jar.md index 91420e10..be893f77 100644 --- a/IdentityServer/v6/docs/content/tokens/jar.md +++ b/IdentityServer/v6/docs/content/tokens/jar.md @@ -14,7 +14,7 @@ You can either transmit them by value or by reference to the authorize endpoint Duende IdentityServer requires the request JWTs to be signed. We support X509 certificates and JSON web keys, e.g.: -```cs +``` var client = new Client { ClientId = "foo", @@ -45,7 +45,7 @@ If the *request_uri* parameter is used, IdentityServer will make an outgoing HTT You can customize the HTTP client used for this outgoing connection, e.g. to add caching or retry logic (e.g. via the Polly library): -```cs +``` builder.AddJwtRequestUriHttpClient(client => { client.Timeout = TimeSpan.FromSeconds(30); diff --git a/IdentityServer/v6/docs/content/tokens/password_grant.md b/IdentityServer/v6/docs/content/tokens/password_grant.md index f50034d3..d14e7158 100644 --- a/IdentityServer/v6/docs/content/tokens/password_grant.md +++ b/IdentityServer/v6/docs/content/tokens/password_grant.md @@ -30,7 +30,7 @@ password=password ### .NET client library On .NET you can use the [IdentityModel](https://identitymodel.readthedocs.io/en/latest/) client library to [request](https://identitymodel.readthedocs.io/en/latest/client/token.html) tokens using the *password* grant type, e.g.: -```cs +``` using IdentityModel.Client; var client = new HttpClient(); @@ -52,7 +52,7 @@ var response = await client.RequestPasswordTokenAsync(new PasswordTokenRequest Since this flow is not generally recommended, no standard implementation for validating the token request and user credentials is included. To add support for it you need to to implement and [register]({{< ref "/reference/di#additional-services" >}}) an implementation of the *IResourceOwnerPasswordValidator* interface:: -```cs +``` public interface IResourceOwnerPasswordValidator { /// diff --git a/IdentityServer/v6/docs/content/tokens/pop/dpop.md b/IdentityServer/v6/docs/content/tokens/pop/dpop.md index 47ff4e32..913a28ef 100644 --- a/IdentityServer/v6/docs/content/tokens/pop/dpop.md +++ b/IdentityServer/v6/docs/content/tokens/pop/dpop.md @@ -35,7 +35,7 @@ DPoP is something a client can use dynamically with no configuration in Identity This is a per-client [setting]({{< ref "/reference/models/client#dpop" >}}) in your IdentityServer. There are additional client as well as [global]({{< ref "/reference/options#dpop">}}) DPoP settings to control the behavior. -```csharp +``` new Client { ClientId = "dpop_client", @@ -53,7 +53,7 @@ DPoP is enabled by simply assigning the *DPoPJsonWebKey* on the client configura For example, here's how to configure a client credentials client: -```csharp +``` services.AddClientCredentialsTokenManagement() .AddClient("demo_dpop_client", client => { @@ -65,7 +65,7 @@ services.AddClientCredentialsTokenManagement() And here's how to configure a code flow client: -```csharp +``` services.AddAuthentication(...) .AddCookie("cookie", ...) .AddOpenIdConnect("oidc", ...); @@ -78,7 +78,7 @@ services.AddOpenIdConnectAccessTokenManagement(options => In either case, you will need to create a JWK. One approach to creating a JWK in string format is to use the .NET crypto APIs, for example: -```csharp +``` var rsaKey = new RsaSecurityKey(RSA.Create(2048)); var jsonWebKey = JsonWebKeyConverter.ConvertFromSecurityKey(rsaKey); jsonWebKey.Alg = "PS256"; diff --git a/IdentityServer/v6/docs/content/tokens/pop/mtls.md b/IdentityServer/v6/docs/content/tokens/pop/mtls.md index ff0fc80c..c729d0c4 100644 --- a/IdentityServer/v6/docs/content/tokens/pop/mtls.md +++ b/IdentityServer/v6/docs/content/tokens/pop/mtls.md @@ -28,7 +28,7 @@ In this scenario, the client would create an X.509 certificate on the fly, and u #### .NET Client In .NET it is straight-forward to create an X.509 certificate on the fly and use it to open a TLS connection. -```cs +``` static X509Certificate2 CreateClientCertificate(string name) { X500DistinguishedName distinguishedName = new X500DistinguishedName($"CN={name}"); @@ -59,7 +59,7 @@ static X509Certificate2 CreateClientCertificate(string name) Then use this client certificate on the TLS channel to request the token: -```cs +``` static async Task RequestTokenAsync() { var client = new HttpClient(GetHandler(ClientCertificate)); @@ -91,7 +91,7 @@ static SocketsHttpHandler GetHandler(X509Certificate2 certificate) #### Enabling support in your IdentityServer The last step is to enable that feature in the options: -```cs +``` var builder = services.AddIdentityServer(options => { // other settings diff --git a/IdentityServer/v6/docs/content/tokens/reference.md b/IdentityServer/v6/docs/content/tokens/reference.md index df9fa5f8..26969043 100644 --- a/IdentityServer/v6/docs/content/tokens/reference.md +++ b/IdentityServer/v6/docs/content/tokens/reference.md @@ -12,14 +12,14 @@ The consumer of the token must use the [introspection]({{< ref "/reference/endpo You can set the token type of a client using the following client setting: -```cs +``` client.AccessTokenType = AccessTokenType.Reference; ``` ## Enabling an API to consume reference tokens The introspection endpoint requires authentication - since the client of an introspection endpoint is typically an API, you configure the secret on the *ApiResource*: -```cs +``` var api = new ApiResource("api1") { ApiSecrets = { new Secret("secret".Sha256()) } diff --git a/IdentityServer/v6/docs/content/tokens/refresh.md b/IdentityServer/v6/docs/content/tokens/refresh.md index 45b7b4ab..80575615 100644 --- a/IdentityServer/v6/docs/content/tokens/refresh.md +++ b/IdentityServer/v6/docs/content/tokens/refresh.md @@ -29,7 +29,7 @@ POST /connect/token ### .NET client library On .NET you can leverage the [IdentityModel](https://identitymodel.readthedocs.io) client library to [request](https://identitymodel.readthedocs.io/en/latest/client/token.html) refresh tokens, e.g.: -```cs +``` using IdentityModel.Client; var client = new HttpClient(); diff --git a/IdentityServer/v6/docs/content/tokens/requesting.md b/IdentityServer/v6/docs/content/tokens/requesting.md index 060cd730..58ecce9a 100644 --- a/IdentityServer/v6/docs/content/tokens/requesting.md +++ b/IdentityServer/v6/docs/content/tokens/requesting.md @@ -48,7 +48,7 @@ On .NET you can leverage the [IdentityModel](https://identitymodel.readthedocs.i The above token request would look like this in C#: -```cs +``` using IdentityModel.Client; var client = new HttpClient(); @@ -68,7 +68,7 @@ The [IdentityModel.AspNetCore](https://identitymodel.readthedocs.io/en/latest/as Using this library, you only need to register the token client in DI: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddAccessTokenManagement(options => @@ -86,7 +86,7 @@ public void ConfigureServices(IServiceCollection services) You can then add token management to an HTTP-factory provided client: -```cs +``` services.AddClientAccessTokenClient("client", configureClient: client => { client.BaseAddress = new Uri("https://demo.duendesoftware.com/api/"); @@ -95,7 +95,7 @@ services.AddClientAccessTokenClient("client", configureClient: client => ...and finally use the client with automatic token management in your application code: -```cs +``` public class DataController : Controller { IHttpClientFactory _factory; @@ -187,7 +187,7 @@ The most common client library for .NET is the OpenID Connect [authentication](h You only need to configure it in your startup code: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddAuthentication(options => diff --git a/IdentityServer/v6/docs/content/ui/consent.md b/IdentityServer/v6/docs/content/ui/consent.md index c26c78a8..d3724efc 100644 --- a/IdentityServer/v6/docs/content/ui/consent.md +++ b/IdentityServer/v6/docs/content/ui/consent.md @@ -16,7 +16,7 @@ Consent is used to allow an end user to grant a client access to [resources]({{< In order for the user to grant consent, a consent page must be provided by the hosting application. When IdentityServer needs to prompt the user for consent, it will redirect the user to a configurable *ConsentUrl*. -```csharp +``` builder.Services.AddIdentityServer(opt => { opt.UserInteraction.ConsentUrl = "/path/to/consent"; }) diff --git a/IdentityServer/v6/docs/content/ui/custom.md b/IdentityServer/v6/docs/content/ui/custom.md index bc77defb..435b2e55 100644 --- a/IdentityServer/v6/docs/content/ui/custom.md +++ b/IdentityServer/v6/docs/content/ui/custom.md @@ -21,7 +21,7 @@ To augment the built-in logic, override *ProcessLoginAsync* and/or *ProcessConse The pattern would be to invoke the base implementation and if the result did not cause a login, consent or error, then the custom logic could be tested to determine if it is desired to prevent SSO and instead force the user to interact in some way (e.g. re-login, trigger MFA, accept a EULA, etc). The sample below illustrates: -```cs +``` public class CustomAuthorizeInteractionResponseGenerator : AuthorizeInteractionResponseGenerator { public CustomAuthorizeInteractionResponseGenerator(IdentityServerOptions options, ISystemClock clock, ILogger logger, IConsentService consent, IProfileService profile) diff --git a/IdentityServer/v6/docs/content/ui/error.md b/IdentityServer/v6/docs/content/ui/error.md index 22d4ac05..941ea2c8 100644 --- a/IdentityServer/v6/docs/content/ui/error.md +++ b/IdentityServer/v6/docs/content/ui/error.md @@ -7,7 +7,7 @@ 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]({{}}). When an error occurs, IdentityServer will redirect the user to a configurable *ErrorUrl*. -```csharp +``` builder.Services.AddIdentityServer(opt => { opt.UserInteraction.ErrorUrl = "/path/to/error"; }) @@ -22,7 +22,7 @@ But this allows the user to understand that something went wrong and that they a Details of the error are provided to the error page via a query string parameter. That parameter's name is configurable using the *ErrorId* option. -```csharp +``` builder.Services.AddIdentityServer(opt => { opt.UserInteraction.ErrorId = "ErrorQueryStringParamName"; }) diff --git a/IdentityServer/v6/docs/content/ui/login/_index.md b/IdentityServer/v6/docs/content/ui/login/_index.md index 95be9f21..83b737e6 100644 --- a/IdentityServer/v6/docs/content/ui/login/_index.md +++ b/IdentityServer/v6/docs/content/ui/login/_index.md @@ -14,7 +14,7 @@ This requires a user to present credentials and typically involves these steps: When IdentityServer needs to show the login page, it redirects the user to a configurable *LoginUrl*. -```cs +``` builder.Services.AddIdentityServer(opt => { opt.UserInteraction.LoginUrl = "/path/to/login"; }) @@ -22,7 +22,7 @@ builder.Services.AddIdentityServer(opt => { If no *LoginUrl* is set, IdentityServer will infer it from the *LoginPath* of your Cookie Authentication Handler. For example: -```cs +``` builder.Services.AddAuthentication() .AddCookie("cookie-handler-with-custom-path", options => { @@ -31,7 +31,7 @@ builder.Services.AddAuthentication() ``` If you are using ASP.NET Identity, configure its cookie authentication handler like this: -```cs +``` builder.Services .AddIdentityServer() .AddAspNetIdentity(); diff --git a/IdentityServer/v6/docs/content/ui/login/dynamicproviders.md b/IdentityServer/v6/docs/content/ui/login/dynamicproviders.md index 5f6977f0..a764ca07 100644 --- a/IdentityServer/v6/docs/content/ui/login/dynamicproviders.md +++ b/IdentityServer/v6/docs/content/ui/login/dynamicproviders.md @@ -15,7 +15,7 @@ Support for Dynamic Identity Providers is included in [IdentityServer](https://d The [identity provider store]({{}}) can be used to query the database containing the dynamic providers. -```cs +``` /// /// Interface to model storage of identity providers. /// @@ -38,7 +38,7 @@ This allows the developer to have more control over the customization on the log Here is an example of how the [IdentityServer Quickstart UI](https://github.com/DuendeSoftware/IdentityServer.Quickstart.UI/blob/main/Quickstart/Account/AccountController.cs#L265-L282) uses both interfaces to then present a merged and unified list to the end user: -```cs +``` var schemes = await _schemeProvider.GetAllSchemesAsync(); var providers = schemes @@ -79,7 +79,7 @@ The [identity provider model documentation]({{}}) p If it is needed to further customize the *OpenIdConnectOptions*, you can register in the DI system an instance of *IConfigureNamedOptions\*. For example: -```cs +``` public class CustomConfig : IConfigureNamedOptions { public void Configure(string name, OpenIdConnectOptions options) @@ -98,7 +98,7 @@ If it is needed to further customize the *OpenIdConnectOptions*, you can registe And to register this in the DI system: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.ConfigureOptions(); @@ -111,7 +111,7 @@ If your customization of the *OpenIdConnectOptions* requires per-provider data t This abstraction requires your code to derive from *ConfigureAuthenticationOptions\* (rather than *IConfigureNamedOptions\*). For example: -```cs +``` class CustomOidcConfigureOptions : ConfigureAuthenticationOptions { public CustomOidcConfigureOptions(IHttpContextAccessor httpContextAccessor) : base(httpContextAccessor) @@ -130,7 +130,7 @@ class CustomOidcConfigureOptions : ConfigureAuthenticationOptions(); diff --git a/IdentityServer/v6/docs/content/ui/login/external.md b/IdentityServer/v6/docs/content/ui/login/external.md index 5d5714ca..242c48da 100644 --- a/IdentityServer/v6/docs/content/ui/login/external.md +++ b/IdentityServer/v6/docs/content/ui/login/external.md @@ -23,7 +23,7 @@ To ease integration with external providers, it is recommended to use an authent Supporting an external provider is achieved by simply registering the handler in your IdentityServer's startup. For example, to use employee logins from Azure AD (AAD): -```csharp +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(); @@ -51,7 +51,7 @@ The process of determining which identity provider to use is called *Home Realm To invoke an external authentication handler use the *ChallengeAsync* extension method on the *HttpContext* (or using the MVC *ChallengeResult*). When triggering challenge, it's common to pass some properties to indicate the callback URL where you intend to process the external login results and any other state you need to maintain across the workflow (e.g. such as the [return URL passed to the login page]({{}})): -```cs +``` var callbackUrl = Url.Action("MyCallback"); var props = new AuthenticationProperties @@ -81,7 +81,7 @@ If you are using ASP.NET Identity, many of these technical details are hidden fr One option on an external authentication handlers is called *SignInScheme*. This specifies the cookie handler to manage the state: -```cs +``` services.AddAuthentication() .AddOpenIdConnect("AAD", "Employee Login", options => { @@ -95,7 +95,7 @@ Given that this is such a common practice, IdentityServer registers a cookie han The scheme is represented via the *IdentityServerConstants.ExternalCookieAuthenticationScheme* constant. If you were to use our external cookie handler, then for the *SignInScheme* above you'd assign the value to be the *IdentityServerConstants.ExternalCookieAuthenticationScheme* constant: -```cs +``` services.AddAuthentication() .AddOpenIdConnect("AAD", "Employee Login", options => { @@ -108,7 +108,7 @@ services.AddAuthentication() Alternatively, you can also register your own custom cookie handler instead. For example: -```cs +``` services.AddAuthentication() .AddCookie("MyTempHandler") .AddOpenIdConnect("AAD", "Employee Login", options => @@ -139,7 +139,7 @@ On the callback page your typical tasks are: To access the result of the external login, invoke the *AuthenticateAsync* method. This will read the external cookie to retrieve the claims issued by the external provider and any other state you previously stored when calling *ChallengeAsync*: -```cs +``` // read external identity from the temporary cookie var result = await HttpContext.AuthenticateAsync(IdentityServerConstants.ExternalCookieAuthenticationScheme); if (result?.Succeeded != true) @@ -171,7 +171,7 @@ This value should be used to locate your local user record for the user. Once your callback page logic has identified the user based on the external identity provider, it will log the user in and complete the original login workflow: -```cs +``` var user = FindUserFromExternalProvider(scheme, userId); // issue authentication cookie for user @@ -206,7 +206,7 @@ To use the IdentityServer provided secure data format implementation, simply cal If no parameters are passed, then all OpenID Connect handlers configured will use the IdentityServer provided secure data format implementation: -```cs +``` public void ConfigureServices(IServiceCollection services) { // configures the OpenIdConnect handlers to persist the state parameter into the server-side IDistributedCache. @@ -230,7 +230,7 @@ public void ConfigureServices(IServiceCollection services) If only particular schemes are to be configured, then pass those schemes as parameters: -```cs +``` public void ConfigureServices(IServiceCollection services) { // configures the OpenIdConnect handlers to persist the state parameter into the server-side IDistributedCache. diff --git a/IdentityServer/v6/docs/content/ui/login/local.md b/IdentityServer/v6/docs/content/ui/login/local.md index 5623f73d..3a2d8db5 100644 --- a/IdentityServer/v6/docs/content/ui/login/local.md +++ b/IdentityServer/v6/docs/content/ui/login/local.md @@ -44,7 +44,7 @@ This is the cshtml for the login Razor Page: And this is the code behind for the login Razor Page: -```cs +``` namespace Sample.Pages.Account { public class LoginModel : PageModel diff --git a/IdentityServer/v6/docs/content/ui/login/session.md b/IdentityServer/v6/docs/content/ui/login/session.md index 98811246..f46307a1 100644 --- a/IdentityServer/v6/docs/content/ui/login/session.md +++ b/IdentityServer/v6/docs/content/ui/login/session.md @@ -13,7 +13,7 @@ This API accepts a *ClaimsPrincipal* which contains claims that describe the use IdentityServer requires a special claim called *sub* whose value uniquely identifies the user. On your login page, this would be the code to establish the authentication session and issue the cookie: -```csharp +``` var claims = new Claim[] { new Claim("sub", "unique_id_for_your_user") }; @@ -50,7 +50,7 @@ The claims are: While you can create the *ClaimsPrincipal* yourself, you can alternatively use IdentityServer extension methods and the *IdentityServerUser* class to make this easier: -```cs +``` var user = new IdentityServerUser("unique_id_for_your_user") { DisplayName = user.Username @@ -66,7 +66,7 @@ The scheme that the handler in the authentication system is identified by is fro When configuring IdentityServer, the [AuthenticationOptions]({{}}) expose some settings to control the cookie (e.g. expiration and sliding). For example: -```csharp +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(options => @@ -84,7 +84,7 @@ In addition to the authentication cookie, IdentityServer will issue an additiona If you require more control over the cookie authentication handler you can register your own cookie handler. You can then configure IdentityServer to use your cookie handler by setting the *CookieAuthenticationScheme* on the [AuthenticationOptions]({{}}). For example: -```csharp +``` public void ConfigureServices(IServiceCollection services) { services.AddAuthentication() @@ -101,7 +101,7 @@ public void ConfigureServices(IServiceCollection services) If the *CookieAuthenticationScheme* is not set, the *DefaultAuthenticationScheme* configured for ASP.NET Core will be used instead. Note that the *AddAuthentication* call that sets the default can come after the *AddIdentityServer* call. For example: -```csharp +``` public void ConfigureServices(IServiceCollection services) { // No cookie authentication scheme is set here. diff --git a/IdentityServer/v6/docs/content/ui/login/windows.md b/IdentityServer/v6/docs/content/ui/login/windows.md index 075d99e3..737f66d5 100644 --- a/IdentityServer/v6/docs/content/ui/login/windows.md +++ b/IdentityServer/v6/docs/content/ui/login/windows.md @@ -20,7 +20,7 @@ Typically in your IdentityServer it is advisable to disable the automatic behavi This is done in *ConfigureServices* (details vary depending on in-proc vs out-of-proc hosting):: -```cs +``` // configures IIS out-of-proc settings (see https://github.com/aspnet/AspNetCore/issues/14882) services.Configure(iis => { @@ -45,7 +45,7 @@ is of type *WindowsPrincipal*. The principal will have information like user and group SID and the Windows account name. The following snippet shows how to trigger authentication, and if successful convert the information into a standard *ClaimsPrincipal* for the temp-Cookie approach:: -```cs +``` private async Task ChallengeWindowsAsync(string returnUrl) { // see if windows auth has already been requested and succeeded diff --git a/IdentityServer/v6/docs/content/ui/logout/_index.md b/IdentityServer/v6/docs/content/ui/logout/_index.md index b80191c6..5a243833 100644 --- a/IdentityServer/v6/docs/content/ui/logout/_index.md +++ b/IdentityServer/v6/docs/content/ui/logout/_index.md @@ -16,14 +16,14 @@ This is a potentially complicated process and involves these steps: When IdentityServer needs to show the logout page, it redirects the user to a configurable *LogoutUrl*. -```cs +``` builder.Services.AddIdentityServer(opt => { opt.UserInteraction.LogoutUrl = "/path/to/logout"; }) ``` If no *LogoutUrl* is set, IdentityServer will infer it from the *LogoutPath* of your Cookie Authentication Handler. For example: -```cs +``` builder.Services.AddAuthentication() .AddCookie("cookie-handler-with-custom-path", options => { @@ -32,7 +32,7 @@ builder.Services.AddAuthentication() ``` If you are using ASP.NET Identity, configure its cookie authentication handler like this: -```cs +``` builder.Services .AddIdentityServer() .AddAspNetIdentity(); diff --git a/IdentityServer/v6/docs/content/ui/logout/external.md b/IdentityServer/v6/docs/content/ui/logout/external.md index fc5ca76e..5bc7c608 100644 --- a/IdentityServer/v6/docs/content/ui/logout/external.md +++ b/IdentityServer/v6/docs/content/ui/logout/external.md @@ -25,7 +25,7 @@ The constant *IdentityServerConstants.LocalIdentityProvider* can be used instead To trigger logout at an external provider, use the *SignOutAsync* extension method on the *HttpContext* (or the *SignOutResult* action result in MVC or Razor Pages). You must pass the scheme of the provider as configured in your startup (which should also match the *idp* claim mentioned above). -```csharp +``` public IActionResult Logout(string logoutId) { // other code elided @@ -53,7 +53,7 @@ We can obtain a *logoutId* to use by calling *CreateLogoutContextAsync* API on t For example: -```csharp +``` public async Task Logout(string logoutId) { // other code elided diff --git a/IdentityServer/v6/docs/content/ui/logout/session_cleanup.md b/IdentityServer/v6/docs/content/ui/logout/session_cleanup.md index a0f2da69..447819f7 100644 --- a/IdentityServer/v6/docs/content/ui/logout/session_cleanup.md +++ b/IdentityServer/v6/docs/content/ui/logout/session_cleanup.md @@ -6,18 +6,18 @@ weight: 20 To remove the authentication cookie, simply use the ASP.NET Core *SignOutAsync* extension method on the *HttpContext*. You will need to pass the scheme used (which is provided by *IdentityServerConstants.DefaultCookieAuthenticationScheme* unless you have changed it): -```cs +``` await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme); ``` Or you can use the overload that will simply sign-out of the default authentication scheme: -```cs +``` await HttpContext.SignOutAsync(); ``` If you are integrating with ASP.NET Identity, sign out using its *SignInManager* instead: -```cs +``` await _signInManager.SignOutAsync(); ``` ### Prompting the User to Logout 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..e5373ddd 100644 --- a/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md +++ b/IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md @@ -32,7 +32,7 @@ With the addition and use of server-side sessions, more interesting architectura To enable server-side sessions, use the *AddServerSideSessions* extension method after adding IdentityServer to the DI system: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer() @@ -64,7 +64,7 @@ This claim must be included in the claims when the user's [authentication sessio For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(options => { diff --git a/IdentityServer/v6/docs/content/ui/server_side_sessions/session_expiration.md b/IdentityServer/v6/docs/content/ui/server_side_sessions/session_expiration.md index b3a92c65..dff43da1 100644 --- a/IdentityServer/v6/docs/content/ui/server_side_sessions/session_expiration.md +++ b/IdentityServer/v6/docs/content/ui/server_side_sessions/session_expiration.md @@ -14,7 +14,7 @@ It is enabled by default, but if you wish to disable it or change how often Iden For example: -```cs +``` public void ConfigureServices(IServiceCollection services) { services.AddIdentityServer(options => { diff --git a/IdentityServer/v6/docs/content/ui/server_side_sessions/session_management.md b/IdentityServer/v6/docs/content/ui/server_side_sessions/session_management.md index fe2b3c4d..2a27b0cf 100644 --- a/IdentityServer/v6/docs/content/ui/server_side_sessions/session_management.md +++ b/IdentityServer/v6/docs/content/ui/server_side_sessions/session_management.md @@ -31,7 +31,7 @@ You can optionally filter on a user's claims mentioned above (subject identifier For example: -```cs +``` var userSessions = await _sessionManagementService.QuerySessionsAsync(new SessionQuery { CountRequested = 10, @@ -44,7 +44,7 @@ The results returned contains the matching users' session data, as well as pagin This paging information contains a *ResultsToken* and allows subsequent requests for next or previous pages (set *RequestPriorResults* to true for the previous page, otherwise the next page is assumed): -```cs +``` // this requests the first page var userSessions = await _sessionManagementService.QuerySessionsAsync(new SessionQuery { @@ -78,7 +78,7 @@ There is also a list of client identifiers to control which clients are affected An example to revoke everything for current sessions for subject id *12345* might be: -```cs +``` await _sessionManagementService.RemoveSessionsAsync(new RemoveSessionsContext { SubjectId = "12345" }); @@ -86,7 +86,7 @@ await _sessionManagementService.RemoveSessionsAsync(new RemoveSessionsContext { Or to just revoke all refresh tokens for current sessions for subject id *12345* might be: -```cs +``` await _sessionManagementService.RemoveSessionsAsync(new RemoveSessionsContext { SubjectId = "12345", RevokeTokens = true, diff --git a/IdentityServer/v6/docs/outtakes/application_types.md b/IdentityServer/v6/docs/outtakes/application_types.md index 12e4e2aa..ea016be4 100644 --- a/IdentityServer/v6/docs/outtakes/application_types.md +++ b/IdentityServer/v6/docs/outtakes/application_types.md @@ -14,13 +14,13 @@ A client can be configured to use more than a single grant type (e.g. Authorizat The *GrantTypes* class can be used to pick from typical grant type combinations: -```cs +``` Client.AllowedGrantTypes = GrantTypes.CodeAndClientCredentials; ``` You can also specify the grant types list manually: -```cs +``` Client.AllowedGrantTypes = { GrantType.Code, @@ -85,7 +85,7 @@ Interactive clients should use an authorization code-based flow. To protect agai This is how you would configure an interactive client: -```cs +``` var client = new Client { ClientId = "...", diff --git a/IdentityServer/v6/docs/outtakes/mtls.md b/IdentityServer/v6/docs/outtakes/mtls.md index e344af66..750fcfaf 100644 --- a/IdentityServer/v6/docs/outtakes/mtls.md +++ b/IdentityServer/v6/docs/outtakes/mtls.md @@ -39,7 +39,7 @@ The Microsoft [documentation](https://docs.microsoft.com/en-us/aspnet/core/secur If you are using Nginx (which we found is the most flexible hosting option), you need to register the following service in *ConfigureServices*: -```cs +``` services.AddCertificateForwarding(options => { // header name might be different, based on your nginx config @@ -64,7 +64,7 @@ Once, the certificate has been loaded, you also need to setup the authentication In this scenario we want to support self-signed certificates, hence the ``CertificateType.All`` and no revocation checking. These settings might be different in your environment:: -```cs +``` services.AddAuthentication() .AddCertificate(options => { @@ -85,7 +85,7 @@ In your IdentityServer, the mutual TLS endpoints, can be configured in three way For example: -```cs +``` var builder = services.AddIdentityServer(options => { options.MutualTls.Enabled = true; @@ -109,7 +109,7 @@ For this you need to associate a client certificate with a client in your Identi Use the [DI extensions methods]({{< ref "/reference/di" >}}) to add the services to DI which contain a default implementation to do that either thumbprint or common-name based: -```cs +``` builder.AddMutualTlsSecretValidators(); ``` @@ -118,7 +118,7 @@ or ``SecretTypes.X509CertificateThumbprint`` (for self-issued certificates) to t For example:: -```cs +``` new Client { ClientId = "mtls", @@ -147,7 +147,7 @@ class provides a convenient mechanism to add a client certificate to outgoing re Use such a handler with *HttpClient* to perform the client certificate authentication handshake at the TLS channel. The following snippet is using [IdentityModel](https://identitymodel.readthedocs.io) to read the discovery document and request a token: -```cs +``` static async Task RequestTokenAsync() { var handler = new SocketsHttpHandler(); @@ -200,7 +200,7 @@ The same preparation steps as mentioned above are necessary at the API to be abl Additionally, the API hosting application will need a mechanism to accept the client certificate in order to obtain the thumbprint to perform the confirmation claim validation. Below is an example how an API in ASP.NET Core might be configured for both access tokens and client certificates: -```cs +``` services.AddAuthentication("token") .AddJwtBearer("token", options => { @@ -218,7 +218,7 @@ Finally, a mechanism is needed that runs after the authentication middleware to Below is a simple middleware that checks the claims: -```cs +``` public class ConfirmationValidationMiddlewareOptions { public string CertificateSchemeName { get; set; } = CertificateAuthenticationDefaults.AuthenticationScheme; @@ -272,7 +272,7 @@ public class ConfirmationValidationMiddleware Below is an example pipeline for an API: -```cs +``` app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto @@ -314,7 +314,7 @@ request the token and calling the API, this will give you the desired proof-of-p For this enable the following setting in the options:: -```cs +``` var builder = services.AddIdentityServer(options => { // other settings @@ -327,7 +327,7 @@ var builder = services.AddIdentityServer(options => In this scenario, the client uses *some* client secret (a shared secret in the below sample), but attaches an additional client certificate to the token request. Since this certificate does not need to be associated with the client at the token services, it can be created on the fly: -```cs +``` static X509Certificate2 CreateClientCertificate(string name) { X500DistinguishedName distinguishedName = new X500DistinguishedName($"CN={name}"); @@ -350,7 +350,7 @@ static X509Certificate2 CreateClientCertificate(string name) Then use this client certificate in addition to the already setup-up client secret: -```cs +``` static async Task RequestTokenAsync() { var client = new HttpClient(GetHandler(ClientCertificate));