Authenticating in Flyte#

Tags: Authentication, Infrastructure, Advanced

The Flyte platform consists of multiple components. Securing communication between each component is crucial to ensure the integrity of the overall system.

The following diagram summarizes the components and their interactions as part of Flyte’s auth implementation:

https://raw.githubusercontent.com/flyteorg/static-resources/main/flyte/deployment/auth/flyte-auth-arch-v2.png

In summary, there are two main resources required for a complete auth flow in Flyte:

Identity Layer

The OpenID Connect (OIDC) protocol allows clients (such as Flyte) to confirm the identity of a user, based on authentication done by an Authorization Server. To enable this, you first need to register Flyte as an app (client) with your chosen Identity Provider (IdP).

An authorization server

As defined by IETF’s RFC #6749 , the authorization server’s job is to issue access tokens to clients after verifying the user (resource owner) and getting their consent. In this setup:

The user of Flyte, is the resource owner.

The client is the tool or component that intends to interact with flyteadmin : flytepropeller, flyteconsole or any of the CLI tools like flytectl.

There are two supported options to use an authorization server in Flyte:

Internal authorization server: It comes pre-installed with Flyte and it is a suitable choice for quick start and testing purposes.

External (custom) authorization server: This a service provided by one of the supported IdPs and is the recommended option if your organization needs to retain control over scope definitions and grants, token expiration policies and other advanced security controls.

Note

Regardless of the type of authorization server to use, you will still need an IdP to provide identity through OIDC.

Authentication Setup#

Prerequisites#

The following is required for non-sandbox (non flytectl demo) deployments:

A public domain name (e.g. example.foobar.com)
Routing of traffic from that domain name to the Kubernetes Flyte Ingress IP address

Note

Checkout this community-maintained guide for more information about setting up Flyte in production, including Ingress.

Identity Providers Support#

Flyte supports OAuth2 and OpenId Connect to secure the various connections:

OpenID Connect: used to secure user’s authentication to flyteadmin through the UI.
OAuth2: used to secure connections from clients (i.e. pyflyte, flytectl and flytepropeller) to the flyteadmin service.

Support for these protocols varies per IdP. Checkout the following table to understand the available support level for your IdP:

Feature	Okta	Google free	GCP Identity Service	Azure AD	Auth0	KeyCloak	Github
OpenID Connect (OIDC)	Yes	Yes	Yes	Yes	Yes	Yes	No
Custom Auth Server	Yes	No	Yes	Yes	?	Yes	No

Identity Management layer : OIDC#

In this section, you can find canonical examples of how to set up OIDC on some of the supported IdPs; enabling users to authenticate in the browser.

Create an OAuth2 Client Credential following the official documentation and take note of the client_id and client_secret
In the Authorized redirect URIs field, add http://localhost:30081/callback for sandbox deployments, or https://<your-deployment-URL>/callback for other methods of deployment.

If you don’t already have an Okta account, sign up for one here.
Create an app integration, with OIDC - OpenID Connect as the sign-on method and Web Application as the app type.
Add sign-in redirect URIs:
- http://localhost:30081/callback for sandbox or https://<your deployment url>/callback for other Flyte deployment types.
Optional - Add logout redirect URIs:
- http://localhost:30081/logout for sandbox, https://<your deployment url>/callback for other Flyte deployment types).
Take note of the Client ID and Client Secret

If you don’t have a Keycloak installation, you can use this which provides a quick way to deploy Keycloak cluster on AWS.
Create a realm using the admin console
Create an OIDC client with client secret and note them down. Use the following instructions
Add Login redirect URIs:
- http://localhost:30081/callback for sandbox or https://<your deployment url>/callback for other Flyte deployment types.

Microsoft Entra ID (Azure AD) Setup

In the Azure portal, open Microsoft Entra ID from the left-hand menu.
From the Overview section, navigate to App registrations > + New registration.
- Under Supported account types, select the option based on your organization’s needs.
Configure Redirect URIs
- In the Redirect URI section:
  
  Choose Web from the platform dropdown.
  
  Enter the following URIs based on your environment:
  
  Sandbox: http://localhost:30081/callback
  
  Production: https://<your-deployment-URL>/callback
Obtain Tenant and Client Information
- After registration, go to the app’s Overview page.
- Take note of the Application (client) ID and Directory (tenant) ID—you’ll need these in your Flyte configuration.
Create a Client Secret
- From the Certificates & Secrets tab, click + New client secret.
- Add a Description and set an Expiration period (e.g., 6 months or 12 months).
- Click Add and copy the Value of the client secret— it will be used in the helm values.
If the Flyte deployment will be dealing with user data, set API permissions:
- Navigate to API Permissions > + Add a permission.
- Select Microsoft Graph > Delegated permissions, and add the following permissions:
  email openid profile offline_access User.Read
Expose an API (for Custom Scopes)
- In the Expose an API tab:
  
  Click + Add a scope, and set the Scope name (e.g., access_flyte).
  
  Provide a Consent description and enable Admin consent required and Save.
- Then, click + Add a client application and enter the Client ID of your Flyte application.
Configure Mobile/Desktop Flow (for flytectl)
- Go to the Authentication tab, and click + Add a platform.
- Select Mobile and desktop applications.
- Add following URI: http://localhost:53593/callback
- Scroll down to Advanced settings and enable Allow public client flows.
Update Flyte Configuration - Use the following values in your Flyte Helm chart or configuration files:
- Client ID: <client-id>
- Client Secret: <client-secret>
- Tenant ID: <tenant-id>
- Redirect URI: https://<your-deployment-URL>/callback

For further reference, check out the official Azure AD Docs on how to configure the IdP for OpenIDConnect.

Note

Make sure the app is registered without additional claims. The OpenIDConnect authentication will not work otherwise, please refer to this GitHub Issue and Azure AD Docs for more information.

Apply OIDC Configuration#

Generate a random password to be used internally by flytepropeller
Use the following command to generate a bcrypt hash for that password:

pip install bcrypt && python -c 'import bcrypt; import base64; print(base64.b64encode(bcrypt.hashpw("<your-random-password>".encode("utf-8"), bcrypt.gensalt(6))))'

Go to your values file and locate the auth section and replace values accordingly:

auth:
 enabled: true
 oidc:
   # baseUrl: https://accounts.google.com # Uncomment for Google
   # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
   # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
   # For Okta use the Issuer URI from Okta's default auth server
   baseUrl: https://dev-<org-id>.okta.com/oauth2/default
   # Replace with the client ID and secret created for Flyte in your IdP
   clientId: <client_ID>
   clientSecret: <client_secret>
 internal:
   clientSecret: '<your-random-password>'
   # Use the output of step #2 (only the content inside of '')

   clientSecretHash: <your-hashed-password>

 authorizedUris:
 - https://<your-flyte-deployment-URL>

Save your changes
Upgrade your Helm release with the new values:

helm upgrade <release-name> flyteorg/flyte-binary -n <your-namespace> --values <your-values-file>.yaml

Where:

<release-name> is the name of your Helm release, typically flyte-backend. You can find it using helm ls -n <your-namespace>

Verify that your Flyte deployment now requires successful login to your IdP to access the UI (https://<your domain>/console)
For flytectl / pyflyte, make sure that your local config file ($HOME/.flyte/config.yaml) includes the following option:

admin:
  ...
  authType: Pkce #change from the default `clientCred` to enable client auth without using shared secrets
  ...

Generate a random password to be used internally by flytepropeller
Use the following command to generate a bcrypt hash for that password:

pip install bcrypt && python -c 'import bcrypt; import base64; print(base64.b64encode(bcrypt.hashpw("<your-random-password>".encode("utf-8"), bcrypt.gensalt(6))))'

Take note of the output (only the contents inside ‘’)

Store the client_secret provided by your IdP in a Kubernetes secret as follows:

kubectl edit secret -n <flyte-namespace> flyte-admin-secrets

Where flyte-namespace is the Kubernetes namespace where you have installed Flyte.

Add a new key under stringData:

apiVersion: v1
# Add from here
stringData:
  oidc_client_secret: <client_secret from the previous step>
# End here
data:
...

Save and close your editor.
Go to your Helm values file and verify that the configmap section include the following, replacing the content where indicated:

configmap:
  adminServer:
    server:
      httpPort: 8088
      grpc:
        port: 8089
      security:
        secure: false
        useAuth: true
        allowCors: true
        allowedOrigins:
   # Accepting all domains for Sandbox installation
          - "*"
        allowedHeaders:
          - "Content-Type"

    auth:
      appAuth:
        thirdPartyConfig:
          flyteClient:
            clientId: flytectl
            redirectUri: http://localhost:53593/callback
            scopes:
              - offline
              - all
        selfAuthServer:
          staticClients:
            flyte-cli:
              id: flyte-cli
              redirect_uris:
              - http://localhost:53593/callback
              - http://localhost:12345/callback
              grant_types:
                - refresh_token
                - authorization_code
              response_types:
                - code
                - token
              scopes:
                - all
                - offline
                - access_token
              public: true
            flytectl:
              id: flytectl
              redirect_uris:
                - http://localhost:53593/callback
                - http://localhost:12345/callback
              grant_types:
                - refresh_token
                - authorization_code
              response_types:
                - code
                - token
              scopes:
                - all
                - offline
                - access_token
              public: true
            flytepropeller:
              id: flytepropeller
     # Use the bcrypt hash generated for your random password
              client_secret: "<bcrypt-hash>"
              redirect_uris:
                - http://localhost:3846/callback
              grant_types:
                - refresh_token
                - client_credentials
              response_types:
                - token
              scopes:
                - all
                - offline
                - access_token
              public: false

      authorizedUris:
      # Use the public URL of flyteadmin (a DNS record pointing to your Ingress resource)
        - https://<your-flyte-deployment-URL>
        - http://flyteadmin:80
        - http://flyteadmin.flyte.svc.cluster.local:80
      userAuth:
        openId:
       # baseUrl: https://accounts.google.com # Uncomment for Google
       # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
         # For Okta, use the Issuer URI of the default auth server
         baseUrl: https://dev-<org-id>.okta.com/oauth2/default
         # Use the client ID generated by your IdP
         clientId: <client_ID>
         scopes:
           - profile
           - openid

Additionally, outside the configmap section, add the following block and replace the necessary information:

secrets:
  adminOauthClientCredentials:
  # If enabled is true, and `clientSecret` is specified, helm will create and mount `flyte-secret-auth`.
  # If enabled is true, and `clientSecret` is null, it's up to the user to create `flyte-secret-auth` as described in
  # https://docs.flyte.org/en/latest/deployment/cluster_config/auth_setup.html#oauth2-authorization-server
  # and helm will mount `flyte-secret-auth`.
  # If enabled is false, auth is not turned on.
  # Note: Unsupported combination: enabled.false and clientSecret.someValue
    enabled: true
  # Use the non-encoded version of the random password
    clientSecret: "<your-random-password>"
    clientId: flytepropeller

Save and exit your editor.
Upgrade your Helm release with the new configuration:

helm upgrade <release-name> flyteorg/flyte-binary -n <your-namespace> --values <your-values-file>.yaml

Verify that the flytepropeller, flytescheduler and flyteadmin Pods are restarted and running:

kubectl get pods -n flyte

For flytectl/pyflyte, make sure that your local config file ($HOME/.flyte/config.yaml) includes the following option:

admin:
  ...
  authType: Pkce #change from the default `clientCred` to enable client auth without using shared secrets
  ...

Note

For multi-cluster deployments, you must add this Secret definition block to the values-dataplane.yaml file. If you are not running flytepropeller in the control plane cluster, you do not need to create this secret there.

Note

Congratulations!

It should now be possible to go to Flyte UI and be prompted for authentication. Flytectl should automatically pickup the change and start prompting for authentication as well. If you want to use an external OAuth2 provider for App authentication, please continue reading into the next section.

Custom Authorization Server#

As mentioned previously, Flyte ships with an internal authorization server; hence setting up an external Authorization Server is optional and dependent on your organization’s security requirements.

In this section, you will find instructions on how to setup an OAuth2 Authorization Server in the different IdPs supported by Flyte:

Note

Google IdP

Google IdP does not offer an OAuth2 Authorization Server that could be used to protect external services (For example Flyte). In this case, Google offers a separate Cloud Product called Google Cloud Identity. Configuration for Cloud Identity is not included in this guide. If unavailable, setup can stop here and FlyteAdmin BuiltIn OAuth2 Authorization Server can be used instead.

Okta’s custom authorization servers are available through an add-on license. The free developer accounts do include access, which you can use to test before rolling out the configuration more broadly.

From the left-hand menu, go to Security > API
Click on Add Authorization Server.
Assign an informative name and set the audience to the public URL of FlyteAdmin (e.g. https://example.foobar.com).

Note

The audience must exactly match one of the URIs in the authorizedUris section above

Note down the Issuer URI; this will be used for all the baseUrl settings in the Flyte config.
Go to Scopes and click Add Scope.
Set the name to all (required) and check Required under the User consent option.
Uncheck the Block services from requesting this scope option and save your changes.
Add another scope, named offline. Check both the Required and Include in public metadata options.
Uncheck the Block services from requesting this scope option.
Click Save.
Go to Access Policies, click Add New Access Policy. Enter a name and description and enable Assign to - All clients.
Add a rule to the policy with the default settings (you can fine-tune these later).
Navigate back to the Applications section.
Create an integration for flytectl; it should be created with the OIDC - OpenID Connect sign-on method, and the Native Application type.
Add http://localhost:53593/callback to the sign-in redirect URIs. The other options can remain as default.
Assign this integration to any Okta users or groups who should be able to use the flytectl tool.
Note down the Client ID; there will not be a secret.
Create an integration for flytepropeller; it should be created with the OIDC - OpenID Connect sign-on method and Web Application type.
Check the Client Credentials option under Client acting on behalf of itself.
This app does not need a specific redirect URI; nor does it need to be assigned to any users.
Note down the Client ID and Client secret; you will need these later.
Take note of the Issuer URI for your Authorization Server. It will be used as the baseURL parameter in the Helm chart

You should have three integrations total - one for the web interface (flyteconsole), one for flytectl, and one for flytepropeller.

Navigate to tab Overview, obtain <client id> and <tenant id>
Navigate to tab Authentication, click +Add a platform
Add Web for flyteconsole and flytepropeller, Mobile and desktop applications for flytectl.
Add URL https://<console-url>/callback as the callback for Web
Add URL http://localhost:53593/callback as the callback for flytectl
In Advanced settings, set Enable the following mobile and desktop flows to Yes to enable deviceflow
Navigate to tab Certificates & secrets, click +New client secret to create <client secret>
Navigate to tab Token configuration, click +Add optional claim and create email claims for both ID and Access Token
Navigate to tab API permissions, add email, offline_access, openid, profile, User.Read
Navigate to tab Expose an API, Click +Add a scope and +Add a client application to create <custom scope>

Apply external auth server configuration#

Follow the steps in this section to configure flyteadmin to use an external auth server. This section assumes that you have already completed and applied the configuration for the OIDC Identity Layer.

Go to the values YAML file you used to install Flyte using a Helm chart
Find the auth section and follow the inline comments to insert your configuration:

auth:
  enabled: true
  oidc:
  # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
  # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
  # For Okta, use the Issuer URI of the custom auth server:
    baseUrl: https://dev-<org-id>.okta.com/oauth2/<auth-server-id>
  # Use the client ID and secret generated by your IdP for the first OIDC registration in the "Identity Management layer : OIDC" section of this guide
    clientId: <oidc-clientId>
    clientSecret: <oidc-clientSecret>
  internal:
  # Use the clientID generated by your IdP for the flytepropeller app registration
    clientId: <flytepropeller-client-id>
  #Use the secret generated by your IdP for flytepropeller
    clientSecret: '<flytepropeller-client-secret-non-encoded>'
  # Use the bcrypt hash for the clientSecret
    clientSecretHash: <-flytepropeller-secret-bcrypt-hash>
  authorizedUris:
  # Use here the exact same value used for 'audience' when the Authorization server was configured
  - https://<your-flyte-deployment-URL>

Find the inline section of the values file and add the following content, replacing where needed:

inline:
  auth:
    appAuth:
      authServerType: External
      externalAuthServer:
      # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
      # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
      # For Okta, use the Issuer URI of the custom auth server:
        baseUrl: https://dev-<org-id>.okta.com/oauth2/<auth-server-id>
        metadataUrl: .well-known/oauth-authorization-server
      thirdPartyConfig:
        flyteClient:
          # Use the clientID generated by your IdP for the `flytectl` app registration
          clientId: <flytectl-client-id>
          redirectUri: http://localhost:53593/callback
          scopes:
          - offline
          - all
    userAuth:
      openId:
      # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
      # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
      # For Okta, use the Issuer URI of the custom auth server:
        baseUrl: https://dev-<org-id>.okta.com/oauth2/<auth-server-id>
        scopes:
        - profile
        - openid
      # - offline_access # Uncomment if your IdP supports issuing refresh tokens (optional)
      # Use the client ID and secret generated by your IdP for the first OIDC registration in the "Identity Management layer : OIDC" section of this guide
        clientId: <oidc-clientId>

Save your changes
Upgrade your Helm release with the new configuration:

helm upgrade  <release-name> flyteorg/flyte-core -n <your-namespace> --values <your-updated-values-filel>.yaml

Find the auth section in your Helm values file, and replace the necessary data:

Note

If you were previously using the internal auth server, make sure to delete all the selfAuthServer section from your values file

configmap:
  adminServer:
    auth:
      appAuth:

        authServerType: External

      # 2. Optional: Set external auth server baseUrl if different from OpenId baseUrl.
      externalAuthServer:
      # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
      # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
      # For Okta, use the Issuer URI of the custom auth server:
        baseUrl: https://dev-<org-id>.okta.com/oauth2/<auth-server-id>

        metadataUrl: .well-known/openid-configuration


    userAuth:
      openId:
      # baseUrl: https://<keycloak-url>/auth/realms/<keycloak-realm> # Uncomment for Keycloak and update with your installation host and realm name
      # baseUrl: https://login.microsoftonline.com/<tenant-id>/v2.0 # Uncomment for Azure AD
      # For Okta, use the Issuer URI of the custom auth server:
        baseUrl: https://dev-<org-id>.okta.com/oauth2/<auth-server-id>
        scopes:
        - profile
        - openid
        # - offline_access # Uncomment if OIdC supports issuing refresh tokens.
        clientId: <client id>


secrets:
  adminOauthClientCredentials:
    enabled: true # see the section "Disable Helm secret management" if you require to do so
    # Replace with the client_secret provided by your IdP for flytepropeller.
    clientSecret: <client_secret>
    # Replace with the client_id provided by provided by your IdP for flytepropeller.
    clientId: <client_id>

Save your changes
Upgrade your Helm release with the new configuration:

helm upgrade  <release-name> flyteorg/flyte-core -n <your-namespace> --values <your-updated-values-file>.yaml

secrets:
  adminOauthClientCredentials:
    enabled: true
    clientSecret: <client secret>
    clientId: <client id>
---
configmap:
  admin:
    admin:
      endpoint: <admin endpoint>
      insecure: true
      clientId: <client id>
      clientSecretLocation: /etc/secrets/client_secret
      scopes:
      - api://<client id>/.default
      useAudienceFromAdmin: true
---
configmap:
  adminServer:
    auth:
      appAuth:
        authServerType: External
        externalAuthServer:
          baseUrl: https://login.microsoftonline.com/<tenant id>/v2.0/
          metadataUrl: .well-known/openid-configuration
          AllowedAudience:
          - api://<client id>
        thirdPartyConfig:
          flyteClient:
            clientId: <client id>
            redirectUri: http://localhost:53593/callback
            scopes:
            - api://<client id>/<custom-scope>

      userAuth:
        openId:
        baseUrl: https://login.microsoftonline.com/<tenant id>/v2.0
        scopes:
        - openid
        - profile
        clientId: <client id>

Note

Congratulations

At this point, every interaction with Flyte components -be it in the UI or CLI- should require a successful login to your IdP, where your security policies are maintained and enforced.

Disable Helm secret management#

Alternatively, you can instruct Helm not to create and manage the secret for flytepropeller. In that case, you’ll have to create it following these steps:

Disable Helm secrets management in your values file

secrets:
  adminOauthClientCredentials:
    enabled: true # enable mounting the flyte-secret-auth secret to the flytepropeller.
    clientSecret: null # disable Helm from creating the flyte-secret-auth secret.
    # Replace with the client_id provided by provided by your IdP for flytepropeller.
    clientId: <client_id>

Create a secret declaratively:

 apiVersion: v1
 kind: Secret
 metadata:
  name: flyte-secret-auth
  namespace: flyte
 type: Opaque
 stringData:
# Replace with the client_secret provided by your IdP for flytepropeller.
   client_secret: <client_secret>

Continuous Integration - CI#

If your organization does any automated registration, then you’ll need to authenticate with the client credentials flow. After retrieving an access token from the IDP, you can send it along to flyteadmin` as usual.

Flytectl’s config.yaml can be configured to use either PKCE (Proof key for code exchange) or Client Credentials (Client Credentials) flows.

Update config.yaml as follows:

admin:
    # Update with the Flyte's ingress endpoint (e.g. flyteIngressIP for sandbox or example.foobar.com)
    # You must keep the 3 forward-slashes after dns:
    endpoint: dns:///<Flyte ingress url>

    # Update auth type to `Pkce` or `ClientSecret`
    authType: Pkce

    # Set to the clientId (will be used for both Pkce and ClientSecret flows)
    # Leave empty to use the value discovered through flyteAdmin's Auth discovery endpoint.
    clientId: <Id>

    # Set to the location where the client secret is mounted.
    # Only needed/used for `ClientSecret` flow.
    clientSecretLocation: </some/path/to/key>

    # If required, set the scopes needed here. Otherwise, flytectl will discover scopes required for OpenID
    # Connect through flyteAdmin's Auth discovery endpoint.
    # scopes: [ "scope1", "scope2" ]

To read further about the available config options, please visit here

Flytekit configuration variables are automatically designed to look up values from relevant environment variables.

Important

However, to aid with continuous integration use-cases, Flytekit configuration can also reference other environment variables.

For instance, if your CI system is not capable of setting custom environment variables like FLYTE_CREDENTIALS_CLIENT_SECRET but does set the necessary settings under a different variable, you may use export FLYTE_CREDENTIALS_CLIENT_SECRET_FROM_ENV_VAR=OTHER_ENV_VARIABLE to redirect the lookup. A FLYTE_CREDENTIALS_CLIENT_SECRET_FROM_FILE redirect is available as well, where the value should be the full path to the file containing the value for the configuration setting, in this case, the client secret. We found this redirect behavior necessary when setting up registration within our own CI pipelines.

The following is a listing of the Flytekit configuration values we set in CI, along with a brief explanation.

# When using OAuth2 service auth, this is the username and password.
export FLYTE_CREDENTIALS_CLIENT_ID=<client_id>
export FLYTE_CREDENTIALS_CLIENT_SECRET=<client_secret>

# This tells the SDK to use basic authentication. If not set, Flytekit will assume you want to use the
# standard OAuth based three-legged flow.
export FLYTE_CREDENTIALS_AUTH_MODE=basic

# This value should be set to conform to this
# `header config <https://github.com/flyteorg/flyteadmin/blob/12d6aa0a419ccec81b4c8289fd172e70a2ded525/auth/config/config.go#L124-L128>`_
# on the Admin side.
export FLYTE_CREDENTIALS_AUTHORIZATION_METADATA_KEY=<header name>

# When using basic authentication, you'll need to specify a scope to the IDP (instead of ``openid``, which is
# only for OAuth). Set that here.
export FLYTE_CREDENTIALS_OAUTH_SCOPES=<idp defined scopes>

# Set this to force Flytekit to use authentication, even if not required by Admin. This is useful as you're
# rolling out the requirement.
export FLYTE_PLATFORM_AUTH=True

References#

This collection of RFCs may be helpful to those who wish to investigate the implementation in more depth.

There’s also more detailed information about the authentication flows in the Understanding Authentication.