[BUG] Flyte Admin HTTPRequestCookieToMetadataHandler adds ID token instead of access token to gRPC Metadata

[Sovietaced]

Describe the bug

When requests are made to Flyte Admin with session cookies (usually from Flyte Console) there is some middleware which translates session cookies into gRPC metadata which can be understood by the Flyte Admin gRPC server. Interestingly, the ID token is translated but the access token is not. This results in a number of undesirable side effects:

1. This introduces log spam for every single request made from Flyte console.

Failed to parse Access Token from context. Will attempt to find IDToken. Error: [JWT_VERIFICATION_FAILED] Could not retrieve bearer token from metadata, caused by: rpc error: code = Unauthenticated desc = Request unauthenticated with Bearer

2. This seems to break user identity when using Okta as an IDP. Identity in Flyte Admin is derived from the Okta token subject claim and the value for the ID token is the Okta App ID and the value for the access token is the email address of the user. So with the current functionality all executions triggered by Flyte console have a global user and this breaks identity related execution filtering.

Expected behavior

The Flyte Admin code seems to imply that access tokens are prioritized over id tokens so I think the middleware should do the same and propagate access tokens if they are available.

I would also expect that the user for executions would always be an end user and not an Okta application identifier.

Additional context to reproduce

No response

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes