feat: add Azure Federated Workload Identity support for OIDC SSO login

[cosmincatalin]

Background

When deployed in Kubernetes with Azure Workload Identity, the OIDC SSO integration should be able to authenticate to the identity provider (e.g., Microsoft Entra ID) using a federated token (client_assertion) instead of storing a client_secret. This eliminates the need for secrets management for the OAuth2 token exchange.

Description

Adds a useFederatedCredential option to OIDC integrations. When enabled, the token exchange uses the AZURE_FEDERATED_TOKEN_FILE (injected by the Azure Workload Identity webhook) as a client_assertion JWT bearer instead of client_secret.

• DB migration: use_federated_credential boolean column on oidc_integrations, client_secret made nullable
• Storage/Entity: OIDCIntegration.encryptedClientSecret now string | null, added useFederatedCredential: boolean
• GraphQL schema: clientSecret optional in CreateOIDCIntegrationInput, useFederatedCredential field on type + inputs
• OIDC provider: Validates that either clientSecret or useFederatedCredential is provided on create
• Auth server token exchange (supertokens-at-home.ts): Reads federated token file and sends client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer + client_assertion=<token> instead of client_secret
• UI: Shows federated credential status badge, handles nullable clientSecretPreview

Token exchange with federated credentials:

POST /token
  grant_type=authorization_code
  client_id=<app-registration-client-id>
  client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
  client_assertion=<contents-of-AZURE_FEDERATED_TOKEN_FILE>
  code=<auth-code>
  code_verifier=<pkce-verifier>

[gemini-code-assist]

Code Review

This pull request introduces support for OIDC federated credentials, specifically Azure Workload Identity, allowing authentication without a client secret. Key changes include database migrations to make client secrets optional, GraphQL schema updates, and server-side logic to utilize federated token files during token exchange. Feedback highlights a style guide violation regarding direct process.env access, a performance concern with synchronous file I/O in an asynchronous handler, and a missing validation check in the update logic to ensure a valid authentication method is always configured.

[cosmincatalin]

@n1ru4l, with #7745 in, can you look into merging this one in?

[n1ru4l]

Thank you for this contribution! I added some initial comments with an initial review, it would be great if you could address these. We cannot give an exact timeline yet, but we will try to test this on our cluster and see if it feasible to merge and support soon.

[n1ru4l]

I have been thinking more about Federation Workload Identity and how we want to support it in the future as a Hive Console Cloud feature that we provide all users, which means at some point Hive Console comes with its own built in OIDC discovery and JWKS endpoint, with assigned subjects for each organization.

---

However, I still see in value in this solution as it solves a problem today and is much simpler for self-hosters, without the complexity that the above direction requires.

I have the following feedback and changes I would like to see.

Set the organization for which the file can be used for via an environment variable

Instead of the current approach, where every org can opt-into using the token file, I would prefer this to be more explicit via required configuration.

To me it feels a bit unsettling, that any organization existing on the Hive Console deployment could use this identity file.

My proposal is that new environment variable OIDC_WORKLOAD_FEDERATION_ORGANIZATION_ID, would isolate which exact organization can use the Azure Workload Identity.

OIDC_WORKLOAD_FEDERATION_IDENTITY_PROVIDER=azure
OIDC_WORKLOAD_FEDERATION_ORGANIZATION_ID=<organization-uuid>
AZURE_FEDERATED_TOKEN_FILE=/var/run/secrets/azure/tokens/azure-identity-token

All these three values need to be set during startup.

Startup should fail when:

• The organization ID is malformed
• The file is unreadable
• The file is empty

Remove the use_federated_credential column from pg

Instead whether a org uses federation credentials is read from the configuration.

Remove the nullability for the CreateOIDCIntegrationInput.clientSecret (for now)

Since this is for now a very specific implementation for certain self-hosting environments, I do not (yet) want this to affect the existing API contract we have in Cloud (until we have a solution that also works for our Cloud deployment).

Instead, I think it is an okay tradeoff to require passing a dummy value (which is then never used).

---

@cosmincatalin These changes would make it comfortable enough for me to accept this contribution. Let me know if you have additional thoughts or pushback on these.

[cosmincatalin]

Based on your suggestions, @n1ru4l , I have greatly simplified the PR, to the point where it's way easier to review.

Instead of being able to provide a single organization that can use federation workloads, I thought it's appropriate to be able to do it for any number, by providing a comma separated list of organizations UUIDs in OIDC_WORKLOAD_FEDERATION_ORGANIZATION_IDS.

Earlier migrations, UI code and other complexities have been removed.

Let me know if this is fine.