Flyte

Alright setting the Bearer: accessToken... worked for me woo

Interestingly I'm getting a 401 because the access token doesn't have scope "all" heh.

Based on the auth interceptor logic it looks like it always prefers access token and falls back to ID token: https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L297-L328

We also requests from our team to show the owner of the execution in the UI

And we're trying to plumb some of that identity info to our plugin as well

Right now our situation is that all pyflyte executions have proper users attached to them but all the ones triggered in the UI have the global ID

It matters for a couple reasons

1. It breaks filtering my executions
2. Any execution triggered by the UI is triggered under the same global user

Well for Okta the subject claim will be different between the tokens. For the ID token the subject is 00udlb1wsfEdsiMGs1d7 (okta app id) and for access token its <mailto:jparraga@stackav.com|jparraga@stackav.com>

but why does that matter? if the whole system is using one id?

you’re saying the identity provided in the id token is different than the identity provided by the access token?

So once the requests hits the gRPC later you'll always see id token related identity (subject claim) instead of access token related identity

OK I'm fairly certain this is the reason: https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L353-L396 This gateway middleware only ever sets the ID token scheme and never the Bearer scheme with the access token

Looks like when the requests gets to the gRPC layer the header is Authorization: IDToken ...

I'll report back after looking some more

Ah ok so this pulls from the identity context... which seems to be populated from the ID token which is not what I want..

Ah its grpc-gateway and not on the http server got it

Where is this /me handler defined?

Yeah so /me which I can't find in flyteadmin yet seems to return the id token which is my problem

would be most grateful. helps us keep track when the person who’s actually going to benefit is the issue creator

https://flyte-org.slack.com/archives/CP2HDHKE1/p1730240402746159

make that other ticket also when you get a chance plz

is it in /me

  const apiContext = useFlyteApi();
  const userId = profile.value?.subject ?? '';```

Need to figure out how flyte console determines what user it is

Yeah the access token is definitely available.. I wonder why filtering by execution IDs results in a request like api/v1/executions/inference/development?filters=eq(user,00udlb1wsfEdsiMGs1d7)&limit=100&sort_by.direction=DESCENDING&sort_by.key=created_at

I think you're right but I need to do some testing since I never seen the access token cookie for some reaosn

I'm going to test out a fix in a bit

There are no calls to that method.

or am i missing something

isn’t that what https://github.com/flyteorg/flyte/blob/f14348165ccdfb26f8509c0f1ef380a360e59c4d/flyteadmin/auth/cookie_manager.go#L156|this does?

is it not?

Hmm that seems like a bug because there is code to delete/retrieve the access token cookie but never any code that writes it

Looks like the cookie manager never stores a secure cookie for the access token.

Hello. I'm investigating an issue where the user identity for Flyte Console based requests always seems to be our Flyte Console Okta App ID (despite logging in as an Okta user). From the limited investigation I've done I've noticed that Flyte Console only seems to have ID tokens related cookies and no access token related cookies. I'm curious if anyone else has any ideas why this is the case before I dig further into the code. I validated that the login flow with Okta produces both an ID token and an access token. The access token is the one with a proper user subject claim.