Workload Identity Federation
Workload Identity Federation (워크로드 아이덴티티 페더레이션)
Workload Identity Federation(WIF)은 오래 지속되는 sk-ant-... API 키 대신 수명이 짧은 OpenID Connect(OIDC) 토큰으로 워크로드가 Claude API에 인증하게 해 주는 기능이에요. 토큰은 내가 이미 운영 중인 아이덴티티 공급자(IdP), 즉 AWS IAM, Google Cloud, 또는 GitHub Actions, Kubernetes, SPIFFE, Microsoft Entra ID, Okta 같은 표준 호환 OIDC 발급자에서 옵니다.
워크로드는 내 아이덴티티 공급자의 서명된 JWT를 제시해요. Anthropic은 Clausnl Console에서 구성한 신뢰 규칙에 대해 그것을 검증하고, 조직의 서비스 계정에 바인딩된 수명이 짧은 Anthropic 접근 토큰을 반환해요. 만들고, CI에 저장하고, 회전하고, 유출할 정적 시크릿이 없어요.
Workload Identity Federation은 정적 API 키를 "만료되지 않는" 토큰 대신 분 단위로 만료되는 토큰으로 대체해 보안 상태를 강화해요. 하지만 그것만으로 완전한 보안 이야기는 아니에요. 페더레이션 인증은 JWT를 서명하는 업스트림 아이덴티티 공급자만큼만 강하니까요. 심층 방어를 위해 Workload Identity Federation을 IdP가 이미 지원하는 제어(워크로드 아이덴티티 바인딩, 조건부 액세스, 감사 로깅)와 함께 조합하세요.
출처: 문서
본문
개념
어떤 워크로드도 페더레이션하기 전에 Claude Console에서 세 리소스를 구성해요. 함께 "발급자 X가 서명하고, Y처럼 보이는 클레임을 가진 토큰은 서비스 계정 Z로 행동할 수 있다"를 표현해요.
서비스 계정(Service accounts)
서비스 계정(svac_...)은 내 Anthropic 조직 안의 명명된 비인간 아이덴티티예요. 서비스 계정 키나 페더레이션 토큰이 행동하는 주체이지요. 서비스 계정은 조직 수준에 존재하며, 워크스페이스의 구성원으로 추가하면 그 워크스페이스에서 활성화돼요. 교환 시 Anthropic은 페더레이션 규칙의 워크스페이스가 서비스 계정의 워크스페이스 구성원 자격 중 하나와 일치하는지 확인하고, 발행된 토큰은 API 키처럼 그 워크스페이스의 속도 제한과 사용량 귀속을 따르게 돼요. 사람 사용자와 달리 서비스 계정은 이메일도, 비밀번호도, Console 로그인도 없어요. 모든 서비스 계정은 조직의 기본 워크스페이스의 구성원으로 암시되며, 행동해야 할 다른 워크스페이스에는 명시적 구성원 자격을 추가하세요. 모든 워크스페이스용(gb) 서비스 계정 키가 한 워크스페이스에서 행동하게 하려면 그 워크스페이스에 서비스 계정을 추가하세요.
워크스페이스 API 키와의 핵심 차이: 워크스페이스 API 키 는 자격 증명인 반면, 서비스 계정 은 자격 증명을 가져요. 어떤 워크로드가 어떤 서비스 계정으로 행동했는지 더 쉽게 감사할 수 있어요.
페더레이션 발급자(Federation issuers)
페더레이션 발급자(fdis_...)는 OIDC 아이덴티티 공급자를 조직에 등록해요. 발급자 등록은 Anthropic에 "이 공급자가 서명한 JWT는 내 조직의 워크로드 아이덴티티를 주장할 수 있다"고 알려줘요.
발급자는 두 가지 구성 요소를 가져요:
- Issuer URL: 공급자의 JWT에 나타나는 정확한
iss클레임 값. 예:https://token.actions.githubusercontent.com또는https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE. - JWKS 소스: JWT 서명을 검증하는 공개 키를 Anthropic이 가져오는 방법. 발급자 URL에서
/.well-known/openid-configuration을 제공하는 공급자에는discovery(기본)를 사용하세요. JWKS 엔드포인트를 직접 가리키려면explicit_url, 공개 인터넷에서 도달할 수 없는 발급자(예: 사설 Kubernetes 클러스터)에는inline을 사용해 키 집합을 업로드하세요.
발급자와 JWKS URL은 https, 포트 443, 공개 IP 주소로 해석되는 공개 DNS 호스트 이름이어야 해요. IP 리터럴은 받지 않아요. 이 제약은 Anthropic이 가져오는 URL에만 적용되며, explicit_url과 inline 모드에서는 issuer_url이 문자열로 비교되고 내부 호스트 이름을 참조할 수 있어요.
보통 환경당 발급자 하나를 등록해요. 내 프로덕션 EKS 클러스터, 스테이징 클러스터, GitHub Actions는 셋 다 별개 발급자예요.
페더레이션 규칙(Federation rules)
페더레이션 규칙(fdrl_...)은 발급자와 서비스 계정 사이의 다리예요. "발급자 X의 JWT에 Y처럼 보이는 클레임이 있으면, 범위 S로 서비스 계정 Z의 토큰을 발행한다."
규칙은 일치 조건, 대상, 그리고 규칙이 일치할 때 적용되는 권한 부여 범위와 토큰 수명을 정의해요:
- Match: 들어오는 JWT가 충족해야 하는 조건.
subject_prefix(예:system:serviceaccount:prod:worker, 또는 접두사 일치용 끝자리*), 정확한audience, 정확한 클레임 값 맵, 복잡한 로직용 CELcondition표현식, 또는 어떤 조합으로 일치할 수 있어요.subject_prefix,claims,condition중 적어도 하나는 설정되어야 하고, JWT가 받아들여지려면 구성된 모든 매처가 통과해야 해요. - Target: 일치한 JWT가 매핑되는 서비스 계정.
- Authorization: 발행된 토큰에 부여되는 OAuth
scope. 기본은workspace:developer로, 워크스페이스 API 키와 같은 접근을 부여해요. 일부 제품은 자체 흐름에서 규칙을 만들 때 범위를 잠가요. 예를 들어 MCP 터널 터널 생성 모달은workspace:manage_tunnels로 범위 제한된 규칙을 만들어요. OAuth 범위 참고. 규칙은token_lifetime_seconds도 설정한다(60~86400, 기본 3600).
단일 발급자는 팀별, 네임스페이스별, 권한 수준별로 많은 규칙을 가질 수 있어요. 규칙은 ID로 평가돼요. 클라이언트가 교환 요청에서 사용할 규칙을 지정하고, Anthropic은 JWT가 그 규칙의 일치 기준을 충족하는지 검증해요. 암시적 규칙 검색은 없어요.
작동 방식
- IdP가 워크로드에 JWT를 발행한다. 대부분의 플랫폼에서 이것은 환경적이에요. Kubernetes 프로젝티드 서비스 계정 토큰, Google Cloud 메타데이터 서버, Azure IMDS, GitHub Actions OIDC 엔드포인트 같은 것. JWT의
iss클레임은 공급자를 식별하고,sub와 다른 클레임은 특정 워크로드를 식별해요. - SDK가 JWT를 Anthropic 접근 토큰으로 교환한다. SDK는 RFC 7523
jwt-bearer부여로POST /v1/oauth/token에 JWT를 보내요. Anthropic은 발급자의 JWKS와 페더레이션 규칙의 일치 조건에 대해 JWT를 검증한 뒤, 규칙의 대상 서비스 계정을 대신해 행동하는 수명이 짧은sk-토큰을 반환해요. - SDK가 모든 요청에 토큰을 보내고 만료 전에 갱신한다. 응용 코드는
api_key없이 클라이언트를 구성하고 평소처럼 API를 호출해요. SDK는 토큰이 만료되기 전에 교환을 다시 실행해요.
페더레이션 설정
내 Anthropic 조직에서 admin, owner, primary owner 역할, 도달 가능한 JWKS 엔드포인트(또는 에어갭 클러스터용으로 붙여 넣을 JWKS 문서)가 있는 OIDC 가능 아이덴티티 공급자, 그리고 그 공급자에서 아이덴티티 토큰을 얻을 수 있는 워크로드가 필요해요.
Connect workload 마법사는 세 리소스(발급자, 서비스 계정, 페더레이션 규칙)를 하나의 안내 흐름에서 모두 만든 뒤 연결을 종단 간 검증해요.
- Connect workload 열기 Claude Console에서 Settings → Workload identity로 가서 Connect workload를 선택하세요.
- 공급자 선택 내 아이덴티티 공급자의 타일을 선택하세요: GitHub Actions, AWS, Google Cloud, Microsoft Entra ID, Kubernetes. 각 타일은 발급자 URL 패턴과 그 공급자의 JWT가 지원하는 일치 필드를 미리 채워요. 다른 표준 호환 공급자(예: SPIFFE, Okta)에는 Custom OIDC를 선택하세요.
- 안내 필드 채우기
마법사가 공급자별 필드를 안내해요. 발급자 구성, 들어오는 JWT의 일치 조건, 만들 서비스 계정과 페더레이션 규칙의 이름. 마법사는
oauth_scope=workspace:developer와token_lifetime_seconds=600을 미리 채워요(token_lifetime_seconds를 생략할 때 API 기본값은 3600). 워크로드가 다른 범위나 수명이 필요하면 조정하세요. - 발급자 검증 선택적으로 아무것도 만들기 전에 발급자 구성을 드라이런하려면 Verify issuer를 선택하세요. 검증은 Anthropic이 내가 입력한 URL에서 JWKS를 가져와 파싱할 수 있는지 확인하며, 도달 가능성과 구성 실수를 일찍 잡아줘요.
- 연결 테스트
마법사가 발급자, 서비스 계정, 페더레이션 규칙을 만든 뒤 15분 동안 성공적인 토큰 교환을 기다려요. 그 창 안에서 워크로드에서 교환을 트리거해(워크로드에서 인증하기) 설정이 작동하는지 확인하세요. 창이 지나도 리소스는 유지되며, 페더레이션 규칙의 세부 페이지에서 테스트를 다시 실행할 수 있어요. 마법사가 만든 규칙의 ID(
fdrl_...)와 서비스 계정 ID(svac_...)를 기록하세요. 워크로드는 조직 ID(및 규칙이 둘 이상의 워크스페이스를 다룰 때 워크스페이스 ID)와 함께 이를 모든 토큰 교환 요청에 전달해요.
이 리소스들을 프로그래밍 방식으로 관리하려면 curl 워크스루는 Admin API로 WIF 관리하기를, 전체 파라미터 세부사항과 응답 스키마는 Service accounts API reference, Federation issuers API reference, Federation rules API reference를 참고하세요.
워크로드에서 인증하기
페더레이션을 구성하면 워크로드는 런타임에 IdP 발행 JWT를 Anthropic 토큰으로 교환해요. SDK가 교환·갱신 루프를 처리해 줘요. cURL 탭은 셸 스크립트, 디버깅, SDK 지원이 없는 언어를 위한 기본 HTTP 교환을 보여줘요.
SDK 클라이언트 구성하기
클라이언트를 명시적 자격 증명으로 또는 인자 없이 구성할 수 있어요. 인자가 없으면 SDK는 자격 증명 우선순위에 설명된 대로 환경 변수나 활성 프로필에서 자격 증명을 해결해요. 인자 없는 형태는 프로덕션 워크로드의 권장 패턴이에요. 같은 컨테이너 이미지를 어디에나 배포하고 환경별로 ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, ANTHROPIC_WORKSPACE_ID, ANTHROPIC_IDENTITY_TOKEN_FILE을 주입하세요.
# 1. Acquire your IdP's JWT (platform-specific; see the per-provider guides).
JWT=$(cat /var/run/secrets/anthropic.com/token)
# 2. Exchange it for a short-lived Anthropic access token.
RESPONSE=$(curl -sS https://api.anthropic.com/v1/oauth/token \
-H "content-type: application/json" \
-d @- <<JSON
{
"grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
"assertion": "$JWT",
"federation_rule_id": "fdrl_...",
"organization_id": "00000000-0000-0000-0000-000000000000",
"service_account_id": "svac_...",
"workspace_id": "wrkspc_..."
}
JSON
)
ACCESS_TOKEN=$(jq -r .access_token <<<"$RESPONSE")
EXPIRES_IN=$(jq -r .expires_in <<<"$RESPONSE") # seconds; re-exchange before this elapses
# 3. Call the API with the access token in the Authorization header.
curl -sS https://api.anthropic.com/v1/messages \
-H "authorization: Bearer $ACCESS_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @- <<'JSON' | jq -r '.content[] | select(.type == "text") | .text'
{
"model": "claude-opus-5-5",
"max_tokens": 1024,
"messages": [{"role": "user", "content": "Hello, Claude"}]
}
JSON
from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile
client = Anthropic(
credentials=WorkloadIdentityCredentials(
identity_token_provider=IdentityTokenFile(
"/var/run/secrets/anthropic.com/token"
),
federation_rule_id="fdrl_...",
organization_id="00000000-0000-0000-0000-000000000000",
service_account_id="svac_...",
workspace_id="wrkspc_...",
),
)
message = client.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "text"))
import Anthropic from "@anthropic-ai/sdk";
import { oidcFederationProvider } from "@anthropic-ai/sdk/lib/credentials/oidc-federation";
import { identityTokenFromFile } from "@anthropic-ai/sdk/lib/credentials/identity-token";
const client = new Anthropic({
credentials: oidcFederationProvider({
identityTokenProvider: identityTokenFromFile("/var/run/secrets/anthropic.com/token"),
federationRuleId: "fdrl_...",
organizationId: "00000000-0000-0000-0000-000000000000",
serviceAccountId: "svac_...",
workspaceId: "wrkspc_...",
baseURL: "https://api.anthropic.com",
fetch
})
});
const message = await client.messages.create({
model: "claude-opus-5-5",
max_tokens: 1024,
messages: [{ role: "user", content: "Hello, Claude" }]
});
for (const block of message.content) {
if (block.type === "text") {
console.log(block.text);
}
}
client := anthropic.NewClient(
option.WithFederationTokenProvider(
option.IdentityTokenFile("/var/run/secrets/anthropic.com/token"),
option.FederationOptions{
FederationRuleID: "fdrl_...",
OrganizationID: "00000000-0000-0000-0000-000000000000",
ServiceAccountID: "svac_...",
WorkspaceID: "wrkspc_...",
},
),
)
message, err := client.Messages.New(context.TODO(), anthropic.MessageNewParams{
Model: anthropic.ModelClaudeOpus5_5,
MaxTokens: 1024,
Messages: []anthropic.MessageParam{
anthropic.NewUserMessage(anthropic.NewTextBlock("Hello, Claude")),
},
})
if err != nil {
log.Fatal(err)
}
for _, block := range message.Content {
if textBlock, ok := block.AsAny().(anthropic.TextBlock); ok {
fmt.Println(textBlock.Text)
break
}
}
import com.anthropic.client.AnthropicClient;
import com.anthropic.client.okhttp.AnthropicOkHttpClient;
import com.anthropic.config.AuthenticationConfig;
import com.anthropic.config.AuthenticationType;
import com.anthropic.config.IdentityTokenConfig;
import com.anthropic.config.InMemoryProfileConfigProvider;
import com.anthropic.config.ProfileConfig;
import com.anthropic.models.messages.MessageCreateParams;
import com.anthropic.models.messages.Model;
void main() {
AnthropicClient client = AnthropicOkHttpClient.builder()
.fromEnv()
.configurationProvider(InMemoryProfileConfigProvider.of(ProfileConfig.builder()
.organizationId("00000000-0000-0000-0000-000000000000")
.workspaceId("wrkspc_...")
.authentication(AuthenticationConfig.builder()
.type(AuthenticationType.OIDC_FEDERATION)
.federationRuleId("fdrl_...")
.serviceAccountId("svac_...")
.identityToken(IdentityTokenConfig.builder()
.source("file")
.path("/var/run/secrets/anthropic.com/token")
.build())
.build())
.build()))
.build();
var message = client.messages().create(MessageCreateParams.builder()
.model(Model.CLAUDE_OPUS_5_5)
.maxTokens(1024)
.addUserMessage("Hello, Claude")
.build());
IO.println(message.content());
}
using Anthropic.Credentials;
// ...
var credentials = new WorkloadIdentityCredentials(new WorkloadIdentityOptions
{
FederationRuleId = "fdrl_...",
OrganizationId = "00000000-0000-0000-0000-000000000000",
ServiceAccountId = "svac_...",
WorkspaceId = "wrkspc_...",
IdentityTokenProvider = new FileIdentityTokenProvider("/var/run/secrets/anthropic.com/token"),
});
using var client = new AnthropicClient(new ClientOptions { Credentials = credentials });
var message = await client.Messages.Create(new()
{
Model = Model.ClaudeOpus5_5,
MaxTokens = 1024,
Messages = [new() { Role = Role.User, Content = "Hello, Claude" }],
});
foreach (var block in message.Content)
{
if (block.Value is TextBlock textBlock)
{
Console.WriteLine(textBlock.Text);
}
}
use Anthropic\Client;
use Anthropic\Lib\Credentials\CredentialResult;
use Anthropic\Lib\Credentials\IdentityTokenFile;
use Anthropic\Lib\Credentials\TokenCache;
use Anthropic\Lib\Credentials\WorkloadIdentityCredentials;
$client = new Client(credentials: new CredentialResult(
provider: new TokenCache(
new WorkloadIdentityCredentials(
identityProvider: new IdentityTokenFile('/var/run/secrets/anthropic.com/token'),
federationRuleId: 'fdrl_...',
organizationId: '00000000-0000-0000-0000-000000000000',
serviceAccountId: 'svac_...',
workspaceId: 'wrkspc_...',
),
),
));
$message = $client->messages->create(
model: 'claude-opus-5-5',
maxTokens: 1024,
messages: [['role' => 'user', 'content' => 'Hello, Claude']],
);
$textBlock = array_find($message->content, static fn ($block): bool => $block->type === 'text');
echo $textBlock->text . PHP_EOL;
client = Anthropic::Client.new(
credentials: Anthropic::Credentials::WorkloadIdentity.new(
identity_token_provider: Anthropic::Credentials::IdentityTokenFile.new(
"/var/run/secrets/anthropic.com/token"
),
federation_rule_id: "fdrl_...",
organization_id: "00000000-0000-0000-0000-000000000000",
service_account_id: "svac_...",
workspace_id: "wrkspc_..."
)
)
message = client.messages.create(
model: "claude-opus-5-5",
max_tokens: 1024,
messages: [{role: "user", content: "Hello, Claude"}]
)
puts message.content.find { it.type == :text }.text
토큰 교환 응답은 RFC 6749 §5.1을 따르며, 필드 참조는 토큰 교환 응답을 참고하세요.
자격 증명 우선순위
모든 SDK는 같은 5계층 순서로 자격 증명을 해결해요. 생성자 인자, 그다음 ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN, 그다음 명시적 ANTHROPIC_PROFILE, 그다음 페더레이션 환경 변수, 그다음 암시적 활성 프로필. 자격 증명을 산출하는 첫 소스가 이겨요.
경고
ANTHROPIC_API_KEY는 페더레이션 계층 위에 있으므로, 환경에 남은 키가 조용히 페더레이션을 가려요. 워크로드를 API 키에서 Workload Identity Federation으로 마이그레이션할 때 워크로드가 실행되는 곳마다(컨테이너 env, CI 시크릿, 셸 프로필)ANTHROPIC_API_KEY가 설정 해제됐는지 확인하세요. CLI의ant auth status명령이 어떤 소스가 이겼는지 보고해요.
전체 우선순위 표, 계층별 시맨틱, 프로필 파일 스키마는 WIF reference의 자격 증명 우선순위를 참고하세요.
API 키에서 마이그레이션
기존 워크로드를 중단 없이 정적 API 키에서 페더레이션으로 전환하려면:
- 페더레이션을 병렬로 구성. 설정 워크스루를 완료하고 페더레이션 규칙이 워크로드의 토큰과 일치하는지 확인하세요. 지금은 기존
ANTHROPIC_API_KEY를 그대로 두세요. - 어떤 자격 증명이 이기는지 스모크 테스트. 워크로드 안에서
ant auth status를 실행하거나(또는 SDK 디버그 로그를 검사)ANTHROPIC_API_KEY가 우선순위 체인에서 페더레이션 계층 위에 있으므로 이 단계에서는 API 키가 여전히 이겨요. ANTHROPIC_API_KEY를 주입되는 곳마다 해제. CI 시크릿, 컨테이너 환경, 셸 프로필에서 제거하세요(앞 경고 참고).ant auth status를 다시 실행하고 이제 페더레이션 소스가 선택되는지 확인하세요.- API 키 삭제. 워크로드가 페더레이션 토큰으로 실행되면 Claude Console의 Settings → API keys에서 키를 삭제하세요.
토큰 수명과 갱신
발행된 Anthropic 토큰의 수명은 (a) 규칙의 token_lifetime_seconds(기본 3,600초)와 (b) 제시한 IdP JWT의 남은 수명의 두 배 중 더 작은 값이에요. 결과는 절대 60초보다 짧지 않아요. 두 번째 상한은 Anthropic 토큰이 파생된 업스트림 아이덴티티보다 작은 여유 이상으로 오래 살지 않게 막아요.
SDK는 토큰을 캐시하고 botocore를 모델로 한 두 계층 일정으로 갱신해요:
- 권고 갱신(Advisory refresh): 만료 120초 전. SDK는 새 교환을 시도해요. 토큰 엔드포인트에 도달할 수 없으면 SDK는 캐시된 토큰을 계속 서빙하며, 그것은 대략 90초 더 유효해요.
- 필수 갱신(Mandatory refresh): 만료 30초 전. 이 시점의 실패한 교환은 오류를 올려요. 캐시된 토큰은 만료에 너무 가까워 안전하지 않아요.
SDK는 매 교환마다 ANTHROPIC_IDENTITY_TOKEN_FILE을 다시 읽으므로, 회전된 프로젝티드 토큰(Kubernetes 서비스 계정 토큰은 예를 들어 exp보다 훨씬 전에 회전)을 투명하게 집어내요.
기본적으로 jti 클레임을 나르는 아이덴티티 토큰은 단일 사용이에요. 각 교환은 이전에 교환되지 않은 JWT를 제시해야 하고, 재제시는 인증 기록 페이지에서 jti_reused 이유로 실패해요. 워크로드가 아이덴티티 공급자에서 자체 토큰을 가져온다면 캐시된 것을 재사용하는 대신 교환마다 새 JWT를 발행하세요(재시도 루프가 흔한 범인). ANTHROPIC_IDENTITY_TOKEN_FILE에서 읽은 토큰에도 같아요. SDK는 매 교환마다 파일을 다시 읽으므로, 파일은 각 갱신 전에 새 토큰을 담아야 해요. 회전되지 않은 토큰을 다시 읽는 갱신이나, 이미 교환한 토큰을 재제시하는 재시작 프로세스도 같은 방식으로 거부돼요. 발행된 토큰의 수명 안에서 토큰을 회전하면 파일을 갱신 일정보다 앞서 유지할 수 있어요. 토큰 소스가 그렇게 자주 회전할 수 없다면 그 발급자에 대해 check_jti를 최후의 수단으로 끌 수 있어요(발급자의 모든 규칙에서 재생 방지를 제거함). 세부사항은 JWT 검증을 참고하세요.
아이덴티티 공급자
각 가이드는 그 플랫폼에서 JWT가 어디서 오는지, 클레임이 어떻게 생겼는지, 등록할 발급자와 규칙 구성을 다뤄요.
- AWS — STS 웹 아이덴티티 토큰, 또는 EKS IRSA 프로젝티드 토큰.
- Google Cloud — 메타데이터 서버의 Google 서명 아이덴티티 토큰.
- Microsoft Entra ID — Managed Identity(IMDS)와 AKS의 Entra Workload ID.
- GitHub Actions — Actions OIDC 토큰으로 키리스 CI 인증.
- Kubernetes — 프로젝티드 서비스 계정 토큰을 사용하는 자체 관리·온프레미스 클러스터.
- SPIFFE — SPIRE 또는 다른 호환 발급자의 SPIFFE JWT-SVID를 가진 워크로드.
- Okta — client-credentials 흐름을 사용하는 Okta 서비스 애플리케이션.
함께 보기
- Admin API로 WIF 관리하기 — 인프라 코드로 발급자, 서비스 계정, 규칙 만들기.
- WIF reference — 환경 변수, 프로필 파일 스키마, 검증 규칙, 오류 코드.
- 인증 (Authentication) — Anthropic SDK 전반의 모든 인증 옵션.
- Admin API reference — 모든 Admin API 엔드포인트의 생성된 요청·응답 스키마.