Class ClientCredentialsClient
- Namespace
- Fdyay.AccessTokenManagement
- Assembly
- Fdyay.AccessTokenManagement.dll
A registered client-credentials client: where to ask for a token, and as whom.
public sealed class ClientCredentialsClient- Inheritance
-
ClientCredentialsClient
- Inherited Members
Properties
ClientId
The client_id sent with the token request.
public ClientId ClientId { get; set; }Property Value
ClientSecret
The client_secret sent with the token request.
public ClientSecret ClientSecret { get; set; }Property Value
ExpirationSkew
How long before expiry a cached token stops being handed out. Defaults to one minute.
public TimeSpan ExpirationSkew { get; set; }Property Value
Remarks
A token that expires in flight is rejected by the resource server, and the caller sees a 401 it did nothing to deserve. The window has to cover the request's own travel time, so it is a margin rather than a precision setting.
HttpClientName
The named HttpClient the token request itself travels on.
public string? HttpClientName { get; set; }Property Value
Remarks
Not the client the token is later attached to — this one. It exists because the backchannel to the authorization server may need handling the application's outbound calls do not: a development certificate to trust, a proxy, a client certificate.
Scope
The scope to request, or null to let the authorization server decide.
public Scope? Scope { get; set; }Property Value
TokenEndpoint
The authorization server's token endpoint.
public Uri? TokenEndpoint { get; set; }Property Value
TokenRequestTimeout
How long the token request itself may take before it is given up on. Ten seconds.
public TimeSpan TokenRequestTimeout { get; set; }Property Value
Remarks
The bound on how long an outbound hop may hang, and here it is also the bound on how long everything else waits. Token acquisition is single-flighted per client, so one caller makes the request and every other caller that missed the cache queues behind it — which turns a slow authorization server into a stalled application rather than one slow call. Without this the bound was HttpClient's own default of a hundred seconds, which is not a choice anybody made about a hop that exists to keep a fifteen-minute token fresh.
Ten seconds because that is what the two sibling outbound hops already use — the back-channel logout
notification, per relying party, and the JAR request_uri fetch — and for the same reason they
give: somebody is waiting on the answer. This is the third of the three and the only one whose delay is
shared by every concurrent caller.
It bounds one request, so a caller that arrives while another holds the single-flight gate can wait up to twice it: once for the request in front of it, once for its own. A failing endpoint is worse than that, because a failure is deliberately not cached and each queued caller then tries in turn — so n waiting callers cost up to n times this value before the last of them hears about it. That is the gate's shape rather than this setting's, and it is recorded as its own work.