Re: [Wimse] JWT-based workload authentication via OIDC (ab)use

Hi Hannes

Regarding your question on whether <draft-schwenkschuster-oauth-identity-chaining> actually should be an item to be worked on in WIMSE rather than in OAuth, I think that work has specific application in the OAuth ecosystem, but a discussion we can have in OAuth as well as here (some of my co-authors can chime in). Perhaps we need a profile of it for workloads, but that may be getting ahead of things a bit.

Cheers

Pieter

From: Wimse <wimse-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 29, 2023 3:22 PM
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>; Evan Gilman <evan@spirl.com>
Cc: wimse@ietf.org
Subject: Re: [Wimse] JWT-based workload authentication via OIDC (ab)use

Hi all,

after we posted [1] we got feedback that the description of how the workload proceeds interacting with the resource server may be over-specified and too specific and should instead be generalized.

Reading the review feedback from Evan gives me the impression that there is probably a possible separation between

(a) the interaction needed to present the workload with a token and the way to convert that token into something that can be used subsequently through the use of token exchange,

and

(b) the intaction that follows afterwards by the workload.

I sounds a bit like (b) should be aligned with the work in the industry today, for example with [2]. Regarding Brian's draft <draft-schwenkschuster-oauth-identity-chaining>, I couldn't recognize a good alignment with [2]. [2] talks about re-using OpenID Connect while Brian's document doesn't.

Ciao

Hannes

PS: Should <draft-schwenkschuster-oauth-identity-chaining> actually be an item to be worked on in WIMSE rather than in OAuth?

Am 29.11.2023 um 14:52 schrieb Brian Campbell:
On the face of it this sounds a lot like the JWT authorization grant from https://datatracker.ietf.org/doc/html/rfc7523

This draft https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/, which was recently adopted by the OAuth WG<https://mailarchive.ietf.org/arch/msg/oauth/l6dGZNuyH7GyiNX9uz1C9R_SCRc/> attempts to further profile/describe the JWT authorization grant including mention of the metadata/JWKS and a local token exchange to receive the initial token.

On Tue, Nov 28, 2023 at 3:48 PM Evan Gilman <evan@spirl.com<mailto:evan@spirl.com>> wrote:
Hannes' BCP draft on kubernetes workload identity tokens [1] discusses a very common use case where a workload uses a platform-provided JWT to authenticate to another service in a different identity domain. In the case of the BCP, authentication to an OAuth Resource Server is discussed, which uses the platform-provided token to "enter an OAuth domain" and receive an access token. There are similar (perhaps even more popular) patterns e.g. use a platform-provided token to "enter the AWS domain" by exchanging it for a time-limited AWS secret access key. In fact, the latter pattern exists in all three major cloud providers, and has been colloquially coined as "Workload Identity Federation".

Aside from the fact that "Workload Identity Federation" is a very confusing way to describe this pattern, it has emerged as a powerful primitive for cross-domain authentication and access. For example, there are dozens of pages of documentation on how to do this against a variety of targets on the GitHub website [2] ... in fact, it is the recommended way to authenticate GitHub Actions CI runners to pieces of infrastructure.

And yet, there is no standard way to do this.

It works purely due to lax OIDC validators ... my read of the situation is that this flow is an abuse of OIDC and nowhere is this pattern described by text. The following gives a rough idea:
* Workload receives platform token
  * Often via disk (see [1])
  * Platform token has a variety of bits set, depending on platform
  * Token mocks an ID token, with a subject/issuer/audience, but lacking most other things
* Workload calls target token exchange service, provides platform token
  * Target service is branded as OIDC-based authentication
  * Target service is configured with mappings, usually referencing sub claim and sometimes others
  * Target service is configured with issuers
* Target pulls well-known OIDC discovery doc from issuer URL
  * Target follows JWKS link, everything else is ignored
  * (sometimes, target will be directly configured with JWKS URL and skip the discovery doc)
* Target validates presented platform token against issuer using JWKS
  * Target refers to mapping to know what credential to return
* Target returns credential valid in target domain
* Workload proceeds on with its day
It would be really great to capture this flow/pattern in a more formal way. I think WIMSE could be a good place to do that. Even just giving it a name would be valuable.

[1]: https://datatracker.ietf.org/doc/draft-hofmann-wimse-workload-identity-bcp/
[2]: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
--
Wimse mailing list
Wimse@ietf.org<mailto:Wimse@ietf.org>
https://www.ietf.org/mailman/listinfo/wimse

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.