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 wasrecently 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> 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
>     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./
>