# Flyte Authentication

Flyte system consists of multiple components. For the purposes of this document, let's categorize them into server-side and client-side components:
- Admin: A server-side control plane component accessible from console, cli and other backends.
- Catalog: A server-side control plane component accessible from console, cli and other backends.
- Console: A client-side single page react app.
- Cli: A client-side (Command Line Interface) component that interacts with Admin and Catalog.
- Propeller: A server-side data plane component that interacts with both admin and catalog services.

## Required Flows

### User authN using OpenIdConnect
Users accessing the flyte console should be able to login to the configured openIdConnect provider and, optionally after consenting, would be able to access the flyte console and make Client-side queries to flyte admin and catalog services.

[](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4lJXtjb25maWc6IHsgJ2ZvbnRGYW1pbHknOiAnTWVubG8nLCAnZm9udFNpemUnOiAxMCwgJ2ZvbnRXZWlnaHQnOiAxMDB9IH0lJVxuICAgIGF1dG9udW1iZXJcbiAgICBVc2VyLT4-K0Jyb3dzZXI6IC9ob21lXG4gICAgQnJvd3Nlci0-PitDb25zb2xlOiAvaG9tZVxuICAgIENvbnNvbGUtPj4tQnJvd3NlcjogMzAyIC9sb2dpblxuICAgIEJyb3dzZXItPj4rQWRtaW46IC9sb2dpblxuICAgIEFkbWluLT4-LUJyb3dzZXI6IElkcC5jb20vb2lkY1xuICAgIEJyb3dzZXItPj4rSWRwOiBJZHAuY29tL29pZGNcbiAgICBJZHAtPj4tQnJvd3NlcjogMzAyIC9sb2dpblxuICAgIEJyb3dzZXItPj4tVXNlcjogRW50ZXIgdXNlci9wYXNzXG4gICAgVXNlci0-PitCcm93c2VyOiBsb2dpblxuICAgIEJyb3dzZXItPj4rSWRwOiBTdWJtaXQgdXNlcm5hbWUvcGFzc1xuICAgIElkcC0-Pi1Ccm93c2VyOiBhZG1pbi8_YXV0aENvZGU9PGFiYz5cbiAgICBCcm93c2VyLT4-K0FkbWluOiBhZG1pbi9hdXRoQ29kZT08YWJjPlxuICAgIEFkbWluLT4-K0lkcDogRXhjaGFuZ2UgVG9rZW5zXG4gICAgSWRwLT4-LUFkbWluOiBpZHQsIGF0LCBydFxuICAgIEFkbWluLT4-K0Jyb3dzZXI6IFdyaXRlIENvb2tpZXMgJiBSZWRpcmVjdCB0byAvY29uc29sZVxuICAgIEJyb3dzZXItPj4rQ29uc29sZTogL2hvbWVcbiAgICBCcm93c2VyLT4-LVVzZXI6IFJlbmRlciAvaG9tZVxuIiwibWVybWFpZCI6eyJ0aGVtZSI6Im5ldXRyYWwifSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)

### Service authN using OAuth2
Propeller (and potentially other non-user facing services) can also authenticate using client_credentials to the Idp and be granted an access_token valid to be used with admin and other backend services.

[](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgUHJvcGVsbGVyLT4-K0V4dGVybmFsIEF1dGhvcml6YXRpb24gU2VydmVyOiAvdG9rZW4_Y2xpZW50X2NyZWRzJnNjb3BlPWh0dHBzOi8vYWRtaW4vXG4gICAgRXh0ZXJuYWwgQXV0aG9yaXphdGlvbiBTZXJ2ZXItPj4tUHJvcGVsbGVyOiBhY2Nlc3NfdG9rZW5cbiAgICBQcm9wZWxsZXItPj4rQWRtaW46IC9saXN0X3Byb2plY3RzP3Rva2VuPWFjY2Vzc190b2tlbiIsIm1lcm1haWQiOnsidGhlbWUiOiJuZXV0cmFsIn0sInVwZGF0ZUVkaXRvciI6ZmFsc2V9)

### User auth in other clients (e.g. Cli) using OAuth2-Pkce
Users accessing backend services through Cli should be able to use OAuth2-Pkce flow to authenticate (in a browser) to the Idp and be issued an access_token valid to communicate with the intended backend service on behalf of the user.

[](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgYXV0b251bWJlclxuICAgIFVzZXItPj4rQ2xpOiBmbHl0ZS1jbGkgbGlzdC1wcm9qZWN0c1xuICAgIENsaS0-PitBZG1pbjogYWRtaW4vbGlzdC1wcm9qZWN0cy9cbiAgICBBZG1pbi0-Pi1DbGk6IDQwMSBVbmF1dGhvcml6ZWRcbiAgICBDbGktPj4rQWRtaW46IGFkbWluL2NsaWVudC1jb25maWdcbiAgICBBZG1pbi0-Pi1DbGk6IENsaWVudF9pZD08YWJjPiwgLi4uXG4gICAgQ2xpLT4-K0Jyb3dzZXI6IGFkbWluL29hdXRoMj9wa2NlJmNvZGVfY2hhbGxlbmdlPTxjaD4mY2xpZW50X2lkPTxhYmM-JnNjb3BlPXJlYWQsd3JpdGUuLi5cbiAgICBCcm93c2VyLT4-K0FkbWluOiBhZG1pbi9vYXV0aDI_cGtjZS4uLlxuICAgIEFkbWluLT4-LUJyb3dzZXI6IDMwMiBpZHAuY29tL2xvZ2luXG4gICAgQnJvd3Nlci0-PitJZHA6IGlkcC5jb20vbG9naW5cbiAgICBJZHAtPj4tQnJvd3NlcjogMzAyIC9sb2dpblxuICAgIEJyb3dzZXItPj4tVXNlcjogRW50ZXIgdXNlcm5hbWUvcGFzc1xuICAgIFVzZXItPj4rQnJvd3NlcjogbG9naW5cbiAgICBCcm93c2VyLT4-K0lkcDogU3VibWl0IHVzZXJuYW1lL3Bhc3NcbiAgICBJZHAtPj4tQnJvd3NlcjogMzAyIGFkbWluL2xvZ2dlZF9pblxuICAgIEJyb3dzZXItPj4rQWRtaW46IGFkbWluL2xvZ2dlZF9pblxuICAgIE5vdGUgb3ZlciBCcm93c2VyLEFkbWluOiBQb3RlbnRpYWxseSBzaG93IGN1c3RvbSBjb25zZW50IHNjcmVlblxuICAgIEFkbWluLT4-LUJyb3dzZXI6IGxvY2FsaG9zdC8_YXV0aENvZGU9PGFiYz5cbiAgICBCcm93c2VyLT4-K0NsaTogbG9jYWxob3N0L2F1dGhDb2RlPTxhYmM-XG4gICAgQ2xpLT4-K0FkbWluOiBhZG1pbi90b2tlbj9hdXRoQ29kZT08YWJjPiZjb2RlX3ZlcmlmaWVyPTx2ZXJpZmllcj4uLi5cbiAgICBBZG1pbi0-Pi1DbGk6IGFjY2Vzc190b2tlblxuICAgIENsaS0-PitBZG1pbjogYWRtaW4vbGlzdF9wcm9qZWN0cy8_YWNjZXNzX3Rva2VuXG4gICAgQWRtaW4tPj4tQ2xpOiBwcm9qZWN0MSwgcHJvamVjdDJcbiIsIm1lcm1haWQiOnt9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)

### Detailed workflow for flytectl

In a multitenant admin environment it would be crucial to support authentication and authorization of the users so that they are allowed to interact with only those resources which they are authorized to do so.

The Admin would be providing support for a single OpenIdConnect provider currently for authentication. This capability can be enhanced later to support multiple providers. TODO : Add reference to how this capability is enabled in admin

With admin enabled with OpenId/Oauth, currently flytectl throws an exception when accessing any admin resource since it doesn't support talking to an Oauth enabled admin.

> error: rpc error: code = Unauthenticated desc = token parse error [JWT_VERIFICATION_FAILED] Could not retrieve
bearer token from metadata, caused by: rpc error: code = Unauthenticated desc = Request unauthenticated with Bearer

The proposed sequence diagram in the previous section highlights the interactions required to support this talk with an Oauth enabled admin.

On receiving the above error code, flytectl would start the Oauth workflow to authenticate the user first using the OpenId provider and then admin server taking the responsibility of doing the authorization.
1. flytectl would fetch the client configuration from admin which will return the client-id, redirect-url and scopes avaiable etc to be used.
eg:
> http://localhost:30081/config/v1/flyte_client which returns data from ThirdPartyConfigOptions and scopes of the ServerConfig. Two scopes of read/write will be supported by the admin

> {"authorization_metadata_key":"flyte-authorization","client_id":"client-id","redirect_uri":"http://localhost:<:port>/flyte-ctl-callback","scopes":["read","write"]}

Note :Verify that redirect_uri should match the callback url sent by flytectl during fetching the authtoken ? confirm this

2. flytectl should lookup the oauth2 authorize and token endpoint of the admin.
admin can expose the .well_known endpoint where it keeps this information.

3. flytectl would start the flow by generating a code_verifier
This would be a base64Urlencoded string of random bytes. (Replace the + and / to be safe)
Define length of this code_verifier.(64 bytes => 88 character base64 string)

4. It then generates a code_challenge which would be hash of the code_verifier
eg: SHA256 hash which would 128 bit or 32 bytes
Bse64 encode this hash to get the code_challenger. This would be 44 characters/bytes in length of base64 chars

5. Also it runs an HttpServer on host using the redirect_uri config and path

6. It would open a browser session with the new admin endpoint /oauth2 passing in this codechallenge, method, scopes needed, client-id, auth_mode, authorization_metadata_key

7. The admin server looks up the client-id in its server configuration to find the IDP url corresponding to it and redirects the user to login through the IDP.
The admin server adds the callback url of http://admin/logged_in along with client-id , scopes : [openid, email]

The call back url from the admin should match the configured callback url with the IDP.

8. Along with above parameters, admin also creates a session cookie recording the code_challenge and method which it can then use for generating authCode during the admin callback from IDP.
9. The IDP further redirects the user to login page if he hasn't got a logged in session and user submits his credentials.

10. The IDP after authenticating invokes the registered admin callback.
11. The admin server can choose to fetch the email using the authCode sent by the IDP if needed later which can be used to provide fine grained user level authorization to resources.
eg: [e-mail] -> read permissions
[e-mail] -> read,write permissions

12. The admin server looks up the session to get the session cookie with code_challenge and generates an authCode using it.Define the length of the authCode .TODO.
13. Using the generated authCode , the admin callsback the cli's callback URl which it had sent in the first request.
Should admin verify the configured callback of the cli is the same as the one sent in the first request?

14. The cli's callback receives the request and sends in the code_verifier and authCode in exchange for a token at the admin's configured token url

15. The admin verifies the code_verifier along with the authCode . authCode contains the code_challenge and hence it can validate that its the right cli thats invoking the token request.

16. Admin then generates the access_token and send it as response in the header?
TODO: figure out how to use this access_token with the Admin go api's.
17. flytectl call the resource request by passing in the access_token

# OAuth2 Providers Support

| Feature | Okta | Google free | GC Identity Service | Azure AD | Auth0 |
| --------------- | ---- | ----------- | ------------------- | -------- | ----- |
| OpenIdConnect | Yes | Yes | Yes | Yes | Yes |
| Custom RP | Yes | No | Yes | Yes? | ? |