OIDC - JWT 기반 인증

OIDC - JWT 기반 인증 (OIDC - JWT-based Auth)

JWT를 사용해 관리자/사용자/프로젝트를 프록시에 인증하는 방법을 알려드릴게요.

출처: 문서

본문

엔터프라이즈 기능 JWT 기반 인증을 사용하려면 LiteLLM 엔터프라이즈 라이선스가 필요해요. 무료 30일 체험판 을 시작하거나 데모를 예약 하세요. 엔터프라이즈에 포함된 기능 을 확인해 보세요.

JWT → 가상 키 매핑 (JWT → Virtual Key Mapping) API 키를 배포하지 않고 사용자별 모델 제한, 지출 한도, 속도 제한을 원하세요? JWT → 가상 키 매핑 문서에서 JWT 인증 사용자(예: Claude Code + SSO)를 위한 세밀한 접근 제어를 확인하세요.

사용법 (Usage)

1단계. 프록시 설정 (Setup Proxy)

JWT_PUBLIC_KEY_URL: OpenID 제공자의 공개 키 엔드포인트예요. 보통 {openid-provider-base-url}/.well-known/openid-configuration/jwks 형식이에요. Keycloak에서는 {keycloak_base_url}/realms/{your-realm}/protocol/openid-connect/certs예요.
JWT_AUDIENCE: JWT 디코딩에 사용되는 audience예요. 설정하지 않으면 디코딩 단계에서 audience를 검증하지 않아요.

export JWT_PUBLIC_KEY_URL="" # "https://demo.duendesoftware.com/.well-known/openid-configuration/jwks"

config에 enable_jwt_auth를 설정하세요. 이러면 프록시가 토큰이 JWT인지 확인해요.

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  enable_jwt_auth: True
model_list:
- model_name: azure-gpt-3.5
  litellm_params:
      model: azure/<your-deployment-name>
      api_base: os.environ/AZURE_API_BASE
      api_key: os.environ/AZURE_API_KEY
      api_version: "2023-07-01-preview"

2단계. 스코프가 있는 JWT 만들기 (Create JWT with scopes)

admin / project OpenID 제공자(예: Keycloak)에 litellm_proxy_admin 이라는 클라이언트 스코프를 만드세요. JWT를 생성할 때 사용자에게 litellm_proxy_admin 스코프를 부여하세요.

curl --location 'https://demo.duendesoftware.com/connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={CLIENT_ID}' \
--data-urlencode 'client_secret={CLIENT_SECRET}' \
--data-urlencode 'username=test-{USERNAME}' \
--data-urlencode 'password={USER_PASSWORD}' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'scope=litellm_proxy_admin' # 👈 grant this scope

OpenID 제공자(예: Keycloak)에서 프로젝트용 JWT를 만드세요.

# client_id: 👈 project id
curl --location 'https://demo.duendesoftware.com/connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={CLIENT_ID}' \
--data-urlencode 'client_secret={CLIENT_SECRET}' \
--data-urlencode 'grant_type=client_credential' \

3단계. JWT 테스트 (Test your JWT)

/key/generate / /chat/completions

curl --location '{proxy_base_url}/key/generate' \
--header 'Authorization: Bearer eyJhbG...I...' \
--header 'Content-Type: application/json' \
--data '{}'

curl --location 'http://0.0.0.0:4000/v1/chat/completions' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJhbG...1...' \
--data '{"model": "azure-gpt-3.5", "messages": [ { "role": "user", "content": "What's the weather like in Boston today?" } ]}'

고급 (Advanced)

여러 OIDC 제공자 (Multiple OIDC providers)

LiteLLM이 여러 OIDC 제공자(예: Google Cloud, GitHub Auth)를 기준으로 JWT를 검증하도록 하려면 이 기능을 사용하세요. 환경의 JWT_PUBLIC_KEY_URL 에 OIDC 제공자 URL을 쉼표로 구분한 목록을 설정하세요. 각 항목은 JWKS URL이거나 OIDC discovery URL( .../.well-known/openid-configuration )일 수 있어요. LiteLLM은 discovery 문서를 가져와 그 jwks_uri 를 따릅니다.

export JWT_PUBLIC_KEY_URL="https://demo.duendesoftware.com/.well-known/openid-configuration,https://accounts.google.com/.well-known/openid-configuration"

이렇게 하면 나열된 모든 제공자의 토큰을 하나의 공유 클레임 매핑 세트로 검증해요. 제공자마다 특정 클레임의 의미가 다르다면 per-issuer 클레임 매핑을 대신 사용하세요.

토큰 검증 방식 (How a token is validated)

LiteLLM은 검증되지 않은 JWT 헤더에서 kid 를 읽고 JWT_PUBLIC_KEY_URL 목록을 순서대로 탐색해요. 각 URL에서 해당 제공자의 키 세트를 로드하고 토큰의 kid 와 일치하는 키를 찾아요. 첫 번째 일치에서 끝나고 거기서 탐색을 멈춰요. 나열된 어떤 제공자도 그 kid 를 게시하지 않으면 No matching public key found ( 401 ) 으로 요청을 거부해요. 이 경로에서는 iss 클레임이 키 세트 선택에 관여하지 않으므로, kid 만으로 어떤 제공자의 키를 시도할지 결정돼요. kid 헤더가 없는 토큰은 정확히 하나의 키를 가진 키 세트와만 매칭돼요. 키가 여러 개인 JWKS에서는 거부되므로, 키를 교체(rotate)하는 제공자는 반드시 kid 를 헤더에 넣어야 해요. 키가 선택되면 그 키로 서명이 검증되고 exp (그리고 있으면 nbf 와 iat ) 가 확인돼요. 허용되는 알고리즘은 RS256/384/512, PS256/384/512, ES256/384/512, EdDSA이고, HMAC 서명 토큰( HS* )은 항상 거부돼요. 키 자료는 JWK의 kty , n , e , x , y , crv 멤버에서 읽으므로 RSA, EC, OKP 키 모두 동작하고 x5c 인증서 체인은 무시돼요. aud 와 iss 는 요청할 때만 검증돼요. JWT_AUDIENCE 가 예상 audience(토큰의 aud 가 목록이면 그 값을 포함하면 통과)를 설정하고, JWT_ISSUER 이 예상 iss 를 설정해요. 둘 다 목록의 모든 URL이 공유하는 단일 값이므로, 제공자가 여러 개면 JWT_ISSUER 는 그중 하나만 허용할 수 있어요. 둘 이상의 제공자에 대해 iss 검증이 필요한 설정은 per-issuer 설정 을 사용해야 해요. 둘 다 설정하지 않으면 나열된 어떤 제공자든 서명한 토큰은 어느 앱에서 발급했든 허용되고, 프록시는 첫 사용 시 이를 알리는 경고를 로그에 남겨요.

캐싱과 실패 동작 (Caching and failure behavior)

각 키 세트(및 각 discovery 문서)는 프록시 인증 캐시(Redis가 설정되어 있으면 Redis, 아니면 인메모리)에 litellm_jwtauth.public_key_ttl 초(기본 600) 동안 캐시돼요. kid 미스는 TTL 안에서는 재조회를 트리거하지 않으므로, 제공자가 방금 교체한 키로 서명된 토큰은 캐시가 만료될 때까지 거부돼요. 전송 수준(DNS, connect, TLS, timeout)에서 가져오기(fetch)가 실패하면 LiteLLM은 짧은 백오프로 최대 3번 재시도한 뒤, 동시 요청이 죽은 엔드포인트에 몰리지 않도록 30초 동안 장애를 기억해요. 해당 키 세트의 마지막으로 알려진 정상(last-known-good) 사본이 있고 public_key_ttl + public_key_stale_ttl (기본 600 + 3600초)보다 최신이면 그 사본을 제공하고 경고를 로그에 남겨요. 그렇지 않으면 요청이 503( the identity provider's JWKS endpoint is temporarily unreachable ) 으로 실패하고, 나머지 URL 중 하나에 일치하는 키가 있어도 더 시도하지 않아요. public_key_stale_ttl: 0 으로 설정하면 캐시 사본이 만료되는 즉시 fail-closed로 동작해요. 200이 아닌 응답이나 파싱 불가능한 본문은 재시도도 stale 제공도 되지 않고, 요청을 401로 실패시키며 목록 탐색도 중단해요.

config.yaml

general_settings:
  enable_jwt_auth: true
  litellm_jwtauth:
    public_key_ttl: 600
    public_key_stale_ttl: 3600

Per-issuer 클레임 매핑 (Per-issuer claim mapping)

같은 클레임이 발급 제공자에 따라 다른 의미를 가질 때 litellm_jwtauth.issuers 를 사용하세요. 흔한 경우: 한 제공자는 팀 ID를 sub 에, 다른 제공자는 사용자 ID를 sub 에 넣는 경우라 전역 단일 team_id_jwt_field: "sub" 로는 둘 다 처리할 수 없어요. 각 항목은 토큰의 iss 클레임과 매칭되고, 자체 JWKS URL, audience, 클레임 매핑을 가져요.

config.yaml

general_settings:
  enable_jwt_auth: true
  litellm_jwtauth:
    admin_jwt_scope: "litellm_proxy_admin"
    issuers:
      - issuer: "https://accounts.google.com"
        audience: "my-gcp-audience"
        team_id_jwt_field: "sub"
      - issuer: "https://keycloak.example.com/realms/my-realm"
        jwks_url: "https://keycloak.example.com/realms/my-realm/protocol/openid-connect/certs"
        audience: "my-keycloak-audience"
        user_id_jwt_field: "sub"
        user_email_jwt_field: "email"

이 설정에서 accounts.google.com 의 토큰은 sub 을 팀 ID로 해석하고, Keycloak 토큰은 같은 sub 을 사용자 ID로 해석해요.

Per-issuer 필드

Field	Required	Description
issuer	Yes	Exact expected iss claim value. Matching is an exact string comparison
audience	Yes, unless disable_audience_validation is set	Expected aud for tokens from this issuer
disable_audience_validation	Yes, unless audience is set	Skip audience validation for this issuer. Setting both this and audience is rejected
jwks_url	No	This issuer's JWKS endpoint. Defaults to reading /.well-known/openid-configuration and following its jwks_uri
team_id_jwt_field	No	Claim path to read as the team ID
team_ids_jwt_field	No	Claim path to read as a list of team IDs
user_id_jwt_field	No	Claim path to read as the user ID
user_email_jwt_field	No	Claim path to read as the user email
org_id_jwt_field	No	Claim path to read as the organization ID
end_user_id_jwt_field	No	Claim path to read as the end-user ID

알아두면 좋은 점 (Things to know)

모든 issuer는 audience 또는 disable_audience_validation: true 중 하나를 반드시 설정해야 해요. 그렇지 않으면 LiteLLM이 시작 시 설정을 거부하므로, 제공자의 서명 키를 공유하는 다른 앱이 발급한 토큰이 프록시에 인증될 수 없어요. issuer 항목에서 생략한 클레임 매핑은 최상위 litellm_jwtauth 설정으로 폴백돼요. 전역 team_id_jwt_field: "sub" 를 유지하면서 user_id_jwt_field: "sub" 만 매핑하는 issuer를 추가하면, 그 issuer 토큰은 여전히 sub 에서 팀 ID를 읽어요. 이렇게 하지 않으려면 모든 클레임 매핑을 issuers 로 옮기세요. issuers 는 allow-list가 아니라 추가 라우팅(additive routing)이에요. iss 가 어떤 항목과도 일치하지 않는 토큰은 전역 JWT_PUBLIC_KEY_URL 과 JWT_AUDIENCE 경로로 빠지므로, 나열한 issuer만 허용하고 싶다면 그것들을 설정하지 않은 채로 두세요. 매칭은 iss 만 기준으로 해요. kid 는 키 세트 선택에만 관여해요.

권장 멀티 제공자 설정 (Recommended multi-provider setup)

제공자가 하나보다 많으면 클레임 매핑이 같더라도 공유 목록보다 litellm_jwtauth.issuers 를 권장해요. issuers 항목은 키 조회를 해당 issuer 자체 JWKS로 한정하고, 제공자별로 iss 와 aud 를 검증해요. 공유 목록은 이게 불가능해요. JWT_PUBLIC_KEY_URL 을 설정하지 않은 채로 두면, iss 가 나열되지 않은 토큰은 스코프가 없는 경로로 빠지지 않고 401( Missing JWT Public Key URL ) 로 거부돼요. 위에서 설명한 키 캐싱과 stale-copy 폴백은 각 issuer의 JWKS에 동일하게 적용돼요.

config.yaml

general_settings:
  enable_jwt_auth: true
  litellm_jwtauth:
    user_id_jwt_field: "sub"
    user_email_jwt_field: "email"
    issuers:
      - issuer: "https://keycloak.example.com/realms/my-realm"
        audience: "litellm-proxy"
      - issuer: "https://sts.example-cloud.com"
        jwks_url: "https://sts.example-cloud.com/.well-known/jwks.json"
        audience: "litellm-proxy"

제공자 호환성 (Provider compatibility)

LiteLLM은 어떤 identity provider도 특별 취급하지 않아요. 위에 나열된 알고리즘 중 하나로 토큰을 서명하고, 공개 키를 JWKS로 게시하며(직접 혹은 jwks_uri 를 가진 OIDC discovery 문서를 통해), 해당 JWKS에 나타나는 kid 헤더를 설정하고, 안정적인 iss 값과 설정한 audience를 발급한다면 어떤 issuer든 동작해요. 이 페이지에 나온 Keycloak과 Kubernetes issuer는 이런 방식으로 키를 게시해요. 다른 issuer는 디코딩한 샘플 토큰과 제공자의 JWKS를 기준으로 네 가지를 확인한 뒤에 의존하세요.

문제 해결 (Troubleshooting)

각 거부 이유를 설명하는 JWT Auth: 로그 줄을 보려면 --detailed_debug 플래그로 프록시를 실행하세요.

Symptom	Cause	Fix
401 No matching public key found. keys=[...], kid=...	No listed JWKS contains the token's kid, or the token has no kid and the JWKS has several keys	Confirm the kid from the token header appears in one of the JWKS documents. If the provider just rotated keys, wait out public_key_ttl or restart the proxy
401 Validation fails: Signature verification failed with several providers in JWT_PUBLIC_KEY_URL	Two providers publish the same kid; the shared list picks the first URL that has it and verifies against the wrong key	Use litellm_jwtauth.issuers so the lookup is scoped to the token's issuer
401 Validation fails: Invalid issuer	iss does not equal JWT_ISSUER (shared path) or the matched issuers[].issuer	Copy iss verbatim from a decoded token; trailing slashes and http vs https matter
401 Validation fails: Audience doesn't match or Token is missing the "aud" claim	aud does not contain JWT_AUDIENCE / issuers[].audience, or the token has no aud	Set the audience your provider actually mints (often the client ID), or set disable_audience_validation: true on that issuer if it cannot mint one
401 Validation fails: The specified alg value is not allowed	Token is HMAC-signed or uses an algorithm outside the list above	Configure the provider to sign with RS256 or another asymmetric algorithm
401 OIDC discovery document at ... does not contain a 'jwks_uri' field	The URL contains .well-known/openid-configuration, so it was treated as a discovery document, but it returned a JWKS	Point JWT_PUBLIC_KEY_URL at the discovery document itself, or at a JWKS URL whose path does not contain that segment
503 the identity provider's JWKS endpoint is temporarily unreachable	A JWKS or discovery URL could not be reached and no stale copy was available	Check egress from the proxy to the provider. Raise public_key_stale_ttl to ride out longer outages
401 Missing JWT Public Key URL from environment	iss matched no issuers entry and JWT_PUBLIC_KEY_URL is unset	Add the issuer to issuers, or set JWT_PUBLIC_KEY_URL if unlisted issuers should be accepted

Kubernetes ServiceAccount 인증 (Kubernetes ServiceAccount Authentication)

클러스터에서 실행되는 워크로드가 Kubernetes ServiceAccount 토큰으로 인증하도록 할 수 있어요. 파드가 네이티브 Kubernetes identity로 LiteLLM에 인증하고 싶을 때 유용해요.

전제 조건 (Prerequisites)

Kubernetes 클러스터에 ServiceAccount 토큰 프로젝션(projection)이 활성화되어 있어야 해요 (Kubernetes 1.20+ 기본값).
클러스터의 OIDC issuer에 접근 가능해야 해요 (EKS, GKE, AKS는 자동).

1단계: OIDC Discovery URL 설정 (Configure the OIDC Discovery URL)

JWT_PUBLIC_KEY_URL 을 클러스터의 OIDC discovery 엔드포인트로 설정하세요:

Amazon EKS / Google GKE / Azure AKS / Self-Managed

# Get your EKS OIDC issuer URL
aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer" --output text
# Set the JWKS URL (append /keys to the issuer URL)
export JWT_PUBLIC_KEY_URL="https://oidc.eks.<region>.amazonaws.com/id/<id>/keys"

# GKE uses Google's OIDC provider
export JWT_PUBLIC_KEY_URL="https://container.googleapis.com/v1/projects/<project>/locations/<location>/clusters/<cluster>/jwks"

# Get your AKS OIDC issuer URL
az aks show --name <cluster-name> --resource-group <resource-group> --query "oidcIssuerProfile.issuerUrl" -o tsv
# Set the JWKS URL
export JWT_PUBLIC_KEY_URL="<issuer-url>/openid/v1/jwks"

# For self-managed clusters, check your API server's --service-account-issuer flag
# The JWKS endpoint is typically at:
export JWT_PUBLIC_KEY_URL="https://<api-server>/openid/v1/jwks"

2단계: LiteLLM 설정 (Configure LiteLLM)

Kubernetes ServiceAccount 토큰에서 identity 정보를 추출하도록 LiteLLM을 설정하세요:

general_settings:
  enable_jwt_auth: True
  litellm_jwtauth:
    # Use namespace as team identifier (resolves via team_alias in DB)
    team_alias_jwt_field: 'kubernetes\.io.namespace'

3단계: ServiceAccount 만들고 파드 설정하기 (Create ServiceAccount and Configure Pod)

연결된 secret이 있는 ServiceAccount를 만들고 파드가 토큰을 사용하도록 설정하세요:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-llm-client
  namespace: my-app
---
apiVersion: v1
kind: Secret
metadata:
  name: my-llm-client-token
  namespace: my-app
  annotations:
    kubernetes.io/service-account.name: my-llm-client
type: kubernetes.io/service-account-token
---
apiVersion: v1
kind: Pod
metadata:
  name: llm-client-pod
  namespace: my-app
spec:
  serviceAccountName: my-llm-client
  containers:
  - name: app
    image: my-app:latest
    env:
    - name: LITELLM_TOKEN
      valueFrom:
        secretKeyRef:
          name: my-llm-client-token
          key: token

LiteLLM에서 예상 audience를 설정하세요:

export JWT_AUDIENCE="https://kubernetes.default.svc"

4단계: 네임스페이스용 팀 만들기 (Create Team for Namespace)

네임스페이스와 일치하는 팀( team_alias 사용)을 LiteLLM에 만드세요:

curl -X POST 'http://0.0.0.0:4000/team/new' \
-H 'Authorization: Bearer <PROXY...KEY>' \
-H 'Content-Type: application/json' \
-d '{
    "team_alias": "my-app",
    "team_id": "my-app",
    "models": ["gpt-5.6-terra", "claude-sonnet-5"]
}'

5단계: 토큰 사용 (Use the Token)

파드 안에서 토큰은 LITELLM_TOKEN 환경 변수로 사용할 수 있어요:

# Make a request to LiteLLM using the env var
curl -X POST 'http://0.0.0.0:4000/v1/chat/completions' \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer ***" \
-d '{
  "model": "gpt-5.6-terra",
  "messages": [{"role": "user", "content": "Hello!"}]
}'

예시: ServiceAccount 토큰 구조 (Example: ServiceAccount Token Structure)

Kubernetes ServiceAccount 토큰은 다음과 같이 생겼어요:

{
  "aud": ["litellm-proxy"],
  "exp": 1234567890,
  "iat": 1234567890,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE",
  "kubernetes.io": {
    "namespace": "my-app",
    "pod": {
      "name": "llm-client-pod",
      "uid": "pod-uid"
    },
    "serviceaccount": {
      "name": "my-llm-client",
      "uid": "sa-uid"
    }
  },
  "nbf": 1234567890,
  "sub": "system:serviceaccount:my-app:my-llm-client"
}

고급: 이름 해석으로 네임스페이스를 팀에 매핑 (Advanced: Map Namespace to Team Using Name Resolution)

team_alias_jwt_field 을 사용해 네임스페이스를 팀으로 자동 매핑하세요:

general_settings:
  enable_jwt_auth: True
  litellm_jwtauth:
    user_id_jwt_field: "sub"
    # Map the namespace to team_alias in the database
    team_alias_jwt_field: 'kubernetes\.io.namespace'
    user_id_upsert: true

이렇게 하면 production 네임스페이스의 파드가 team_alias: production 인 팀에 자동으로 연결돼요.

허용할 JWT 스코프 이름 설정 (Set Accepted JWT Scope Names)

LiteLLM이 사용자가 관리자인지 판단할 때 평가하는 JWT 'scopes' 문자열을 변경할 수 있어요.

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  enable_jwt_auth: True
  litellm_jwtauth:
    admin_jwt_scope: "litellm-proxy-admin"

엔드유저 / 내부 사용자 / 팀 / 조직 추적 (Tracking End-Users / Internal Users / Team / Org)

litellm 사용자/팀/조직에 대응하는 JWT 토큰의 필드를 설정하세요. 참고: 모든 JWT 필드는 중첩 클레임에 접근하기 위한 점(dot) 표기법을 지원해요 (예: "user.sub" , "resource_access.client.roles" ).

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  enable_jwt_auth: True
  litellm_jwtauth:
    admin_jwt_scope: "litellm-proxy-admin"
    team_id_jwt_field: "client_id" # 👈 CAN BE ANY FIELD (supports dot notation for nested claims)
    user_id_jwt_field: "sub" # 👈 CAN BE ANY FIELD (supports dot notation for nested claims)
    org_id_jwt_field: "org_id" # 👈 CAN BE ANY FIELD (supports dot notation for nested claims)
    end_user_id_jwt_field: "customer_id" # 👈 CAN BE ANY FIELD (supports dot notation for nested claims)

예상 JWT (평면 구조):

{
  "client_id": "my-unique-team",
  "sub": "my-unique-user",
  "org_id": "my-unique-org"
}

점 표기법을 사용한 중첩 구조:

{
  "user": {
    "sub": "my-unique-user",
    "email": "[email protected]"
  },
  "tenant": {
    "team_id": "my-unique-team"
  },
  "organization": {
    "id": "my-unique-org"
  }
}

중첩 예시 설정:

litellm_jwtauth:
  user_id_jwt_field: "user.sub"
  user_email_jwt_field: "user.email"
  team_id_jwt_field: "tenant.team_id"
  org_id_jwt_field: "organization.id"

이제 litellm은 매 호출마다 DB에서 사용자/팀/조직의 지출을 자동으로 업데이트해요.

ID 대신 이름(별칭)으로 해석 (Resolve by Name (Alias) Instead of ID)

가끔 JWT 토큰에 DB ID 대신 사람이 읽을 수 있는 이름이 들어 있을 수 있어요. LiteLLM은 DB에서 조회해 이 이름들을 ID로 해석할 수 있어요. 사용 사례: IDP가 JWT에 팀/조직 이름을 제공하지만, LiteLLM은 지출 추적과 접근 제어를 위해 실제 DB ID가 필요해요.

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  enable_jwt_auth: True
  litellm_jwtauth:
    # Name-based fields (resolved via database lookup)
    team_alias_jwt_field: "team_alias"       # Resolves team by team_alias in DB
    org_alias_jwt_field: "org_alias"         # Resolves org by organization_alias in DB

예상 JWT:

{
  "sub": "user-123",
  "team_alias": "engineering-team",
  "org_alias": "acme-corp"
}

동작 방식 (How It Works):

LiteLLM이 설정된 JWT 필드에서 이름을 추출해요.
별칭 필드로 DB에서 엔티티를 조회해요: 팀은 LiteLLM_TeamTable의 team_alias 열, 조직은 LiteLLM_OrganizationTable의 organization_alias 열.
해석된 ID로 지출 추적과 접근 제어를 수행해요.

우선 순위 (Precedence): ID 필드는 항상 이름 필드보다 우선해요. team_id_jwt_field 와 team_alias_jwt_field 를 모두 설정했고 JWT에 두 값이 모두 있으면 ID를 사용해요.

# Example: ID takes precedence
litellm_jwtauth:
  team_id_jwt_field: "team_id"        # Used if present in JWT
  team_alias_jwt_field: "team_alias"   # Fallback if team_id not present

중첩 필드 (Nested Fields): 이름 필드도 중첩 클레임용 점 표기법을 지원해요:

litellm_jwtauth:
  team_alias_jwt_field: "organization.team.name"
  org_alias_jwt_field: "company.name"

중요 참고 사항 (Important Notes):

엔티티(팀/조직)가 일치하는 별칭으로 DB에 이미 존재해야 해요.
별칭은 고유해야 해요. 여러 엔티티가 같은 별칭을 공유하면 오류가 반환돼요.

OIDC - JWT 기반 인증