First draft of DPoP support

[brockallen]

First cut of DPoP support. (without a built-in nonce implementation)

Open issues:

• Need an update for the IdentityModel constants
• For clients that are configured to requite DPoP do we require the dpop_jkt param on the authorize endpoint? The spec says OPTIONAL, and that flag will still[ require the client to provide one on the token endpoint.
• We need to think thru the options for replay duration and where those live. Also, this will require the replay cache by default now in DI, which requires an IDistributedCache. (probably related: review ICache<T> and IDistribiutedCache #1059)
• We need to think thru the options for proof token iat duration validation and where those live. Related: do we want iat vs nonce validation to be a per-client setting? I can see a simple built-in nonce implementation that simply returns a DP protected server timestamp. It'd really not be too diff than the iat validation, but it's server-generated. I can see 2 per-client settings: 1) DPoPProofTokenLifetime (or somesuch), and 2) DPoPValidationType (enum iat vs nonce). Our built-in can do both, I think.
• Still need a design for nonce validation and/or extensibility.
• Should we support dpop_jkt with CIBA on the back channel authentication request?
• look at token renewal proof key/cnf binding logic.
• Needs docs and samples. (issues opened elsewhere)

Closes: #1116

[brockallen]

@josephdecock and @leastprivilege we should schedule a time to review this first cut, and all together seems to make sense.

[leastprivilege]

For clients that are configured to requite DPoP do we require the dpop_jkt param on the authorize endpoint? The spec says OPTIONAL, and that flag will still[ require the client to provide one on the token endpoint.

In FAPI 2 the dpop_jkt is mandatory. So this needs a separate Require... setting.

[brockallen]

In FAPI 2 the dpop_jkt is mandatory. So this needs a separate Require... setting.

This seems to say:

if using DPoP, shall support "Authorization Code Binding to DPoP Key" (as required by section 10.1 of [I-D.ietf-oauth-dpop]).

We do support it, so I'm not sure the above is worded such that we need a new client config just for that aspect. Thoughts?

[leastprivilege]

Ok. I misread that.

[brockallen]

For clients that are configured to requite DPoP do we require the dpop_jkt param on the authorize endpoint? The spec says OPTIONAL, and that flag will still[ require the client to provide one on the token endpoint.

Ok, so I think the answer is that we don't need a require flag for this.

[brockallen]

We need to think thru the options for replay duration and where those live. Also, this will require the replay cache by default now in DI, which requires an IDistributedCache. (probably related: #1059)

I added a new DPoPOptions on the IdentityServer options with the validity duration. I guess we also want a clock skew option as well? This might be necessary even for server-generated nonce values.

[brockallen]

Also added a simple nonce implementation that data protects the server time and uses that for the expiration checking. Still need a flag somewhere to trigger this. It feels like it should be per-client.

[brockallen]

Added MVC sample that works with both the OIDC handler and our access token management library. Yet to add API support.

[brockallen]

Docs topics:

• new client config settings (RequireDPoP, DPoPValidationMode, DPoPClockSkew)
• use of IReplayCache
• update authZ and token EP docs with new params

[brockallen]

Updates done for the additional logic on token renewal. We can review when available.

[leastprivilege]

LGTM