oidc_child and idp pre-auth module: add support for RFC 8693 token exchange

[abbra]

RFC 8693 defines a concept of a Security Token Service (STS) that is capable of validating security tokens provided to it and issue new security tokens in response. If an IdP supports RFC 8693, it may be used to request a security token by IPA external IdP OAuth 2.0 client and use it to verify user identity based on the security token of provided by a different OAuth 2.0 applicatiion.

This can be used to allow IPA KDC to issue Kerberos tickets for those OAuth 2.0 applications that want to operate on behalf of a user who they already logged in with the help of OAuth 2.0 authorization framework. While these applications could have used a combination of S4U2Self and S4U2Proxy to perform protocol transition on behalf of the user, there are cases where a user needs to transition to own TGT directly rather than to a service ticket. These cases include situations where an authentication indicators are used to limit access to other services. S4U2Self would not be able to transition to a service ticket with the right (idp) authentication indicator.

Implementation would require following parts:

• idp preauth module would need to support specifying a token on the client side like -X option of kinit allows to achieve that for PKINIT. idp client side would wrap the token into a json container and would send it to KDC as a part of optimistic exchange
• idp preauth module on the KDC side would need to recognize the metadata and pass it through to ipa-otpd similar to the second part of the current flow
• oidc_child would need to accept the passed token and use STS services to exchange it to a proper token using our IdP client credentials
• oidc_child would then use received token to verify user information

Corresponding part for ipa-otpd is tracked with https://pagure.io/freeipa/issue/9156

[abbra]

When discussing this ticket with @sumit-bose, a concern was raised that an attacker could steal a token from a valid OAuth 2.0 client for the same IdP and then present it to exchange to obtain a Kerberos TGT on behalf of the user. This is similar to Access-Token injection attack described in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.6.

[abbra]

FYI, there is a similar discussion by Matthew Garret about ways of tying bearer tokens to specific clients they were issued for: https://mjg59.dreamwidth.org/59704.html. We probably can get some of those ideas for our use case.