선행 사항•
AI Agent가 Okta에 등록돼있어야하며,
등록된 AI Agent의 resource connection 탭에서 작업이 이루어짐
0. 에이전트가 연결 가능한 리소스 타입
•
Okta에 등록된 AI Agent가 어떤 리소스를 연결해서 사용할 수 있는지
# | 리소스 타입 | 역할 | 설명 |
1 | Authorization Servers | 다른 앱/API에 쓸 출입권(토큰)을 발급 해주는 곳 | OAuth 권한 서버가 에이전트에 scope 부여 |
2 | Secrets | API키·비밀번호 같은 비밀 "값" (vault 보관, 런타임에 꺼냄) | Okta에 안전 저장된 민감 자격증명 |
3 | Service Accounts | 대상 시스템의 머신 계정(그 계정으로 로그인해 작업) | 앱별 서비스 계정 (privileged machine identity) |
4 | Applications | 에이전트가 접근할 실제 서비스/앱(SaaS/사내 API) | OIN 앱 또는 custom resource server |
5 | MCP Servers | 에이전트가 호출할 도구 모음(예: 업무 생성) | MCP 서버가 제공하는 도구(capability) |
6 | Other AI Agents (EA) | 에이전트가 호출·위임할 다른 에이전트 | 에이전트 간 위임(agent-to-agent) |
1. Authorization Server
1-1. Authorization Server 생성
경로: Security → API → Authorization Servers → Add Authorization Server
비유토큰을 편지라고 생각해보자
•
audience = 편지 봉투를 받는 사람의 주소
•
okta 인가 서버가 토큰을 발급할때 봉투에 받는 사람: api://mcp-poc라고 도장을 찍어줘
•
mcp 서버는 편지를 받으면 “이거 나한테 온거 맞아?”하고 받는 사람 칸을 확인. 나(api://mcp-poc)한테 온거면 통과 딴데 주소면 거부.
→ 그래서 audience는 “이 토큰은 어느 서버용인가?”를 적는 이름표일 뿐이고, 그 이름은 내가 짓는 것
•
Name: 인가 서버의 표시 이름
•
Audience: 리소스 식별자 = 토큰 aud = MCP_AUDIENCE
•
Desciption: 인가 서버에 대한 설명
•
Scopes 탭에서 OAuth scope 정의 (최소권한 테스트용 2개 이상 권장)
•
Access Policies로 접근 정책 설정
→ 이후 이 서버를 에이전트에 연결
1-2. Scope 생성
•
Name: 실제 scope 문자열(토큰 요청 시 쓰이는 이름)
•
Display phrase: 사람이 보는 표기명
•
Description: 설명
•
User consent: 앱의 접근 여부를 사용자에게 띄울지 결정하는 설정
◦
Implicit: 동의 화면 안 띄움, 자동으로 허용된 것으로 간주
◦
Optional: 동의 필요 여부를 앱 쪽 설정에 위임
◦
Required: 이 scope은 항상 사용자 동의 화면을 강제
•
Default scope: scope 미지정 요청 시 기본 포함 여부
•
Metadata: scopes_supported(discovery)에 노출
1-3. Access policy 및 rule 생성
2. Confidential OAuth 앱 생성
경로: Application → Application → Create App Integration
•
App integration name: 앱 표시 이름
•
Proof of possession: 토큰을 특정 키에 묶어 탈취 시 재사용 방지(고급 보안, 클라이언트가 DPoP 헤더 구현 필요)
•
Grant type → Client Credentials: 사용자 없이 앱 자신으로 토큰을 받는 M2M 방식(체크)
•
Grant type → Authorization Code: Okta MCP 등록 요건(Confidential+auth code)
•
Sign-in redirect URIs: 사용자가 로그인 성공하면 Okta가 인증 code를 돌려보내는 주소.
이 목록에 등록된 URI로만 보냄(보안).
•
Sign-out redirect URIs (Optional): 로그아웃 후 돌아갈 주소. http://localhost:8080 그대로 둬도 무방. 비워도 됨.
•
Base URIs (Optional): Okta Sign-In 위젯을 자체 호스팅할 때만 필요
•
Controlled access: 이 앱을 누가 쓸 수 있는지
•
Enable immediate access: 사용자를 미리 배정 안해도 즉시 접근 허용. 단 End user Dashboard/프로비저닝 기능 비활성
3. MCP Server 생성
MCP 서버가 노출한 도구에 접근
Agent Gateway가 여러 MCP를 virtual MCP로 집약 가능
경로: Directory → MCP Servers → Add MCP server
•
Name: MCP server 이름
•
Description: 설명
•
URL: base URL은 생성 후 변경 불가
•
Client credentials name:
•
Client ID: 생성했던 OIDC 앱의 Client ID
•
Client secret: 생성했던 OIDC 앱의 Client secret
•
Scopes: Authorization server에서 만든 Scopes
4. Authorization server 연결
•
앞서 만들었던 Authroization server를 에이전트에 직접 붙이는 작업
경로: Directory → AI Agents → 만들어놓은 에이전트 선택 → Resource connection → Add resource connection
5. MCP Server 연결
절차: MCP server 목록에서 선택 > Resource Indicator 자동 채워짐
항목 | 결과 | 비고 |
MCP server 연결 | | |
Resource Indicator 확인 | |
TC-2.3. SaaS Application 연결
절차: OIN 앱 또는 custom resource server 선택 > 인스턴스 선택 > Resource Indicator 자동 채워짐
항목 | 결과 | 비고 |
OIN 앱 연결 | | |
custom resource server 연결 | |
TC-2.4. Service Accounts & Secrets 연결 (Okta Privileged Access)
프로젝트 핵심: Dooray 토큰을 .env 대신 vault에서 런타임 획득하려는 목표와 직결.
절차(Secret): secret 선택 > Resource Indicator 수락/수정
절차(Service Account): 앱 + service account 선택 > Resource Indicator 수락/수정
항목 | 결과 | 비고 |
Privileged Access security admin 역할 보유 | | |
Secret 연결 | | |
Service Account 연결 | | |
Resource Indicator 동작 확인 | |
TC-2.5. Other AI Agents 연결 (EA)
절차: agent 선택 > authorization server + audience/resource URL 구성 > scope 지정
항목 | 결과 | 비고 |
EA 활성화 여부 | | managed EA면 보류 |
agent-to-agent 위임 | |
비유 | 우리 실제 | 우리가 한 작업 |
매표소 | Okta Custom Authorization Server mcp-poc-as | 생성 + scope mcp.tools.execute + 발급 정책 |
방문객 신분증 등록 | Okta OIDC 앱 mcp-poc-client | Client ID/Secret 발급받음 (토큰 요청할 자격) |
티켓 | Okta가 발급한 access token | 테스트로 실제 발급받아 확인 (aud/scope 맞음) |
놀이기구 | 우리 MCP 서버(localhost:8010→터널) | 코드로 만듦 + 티켓 검사 로직(JWKS) |
스캔 검사 | MCP 서버의 Bearer 검증 | 테스트: 티켓無→401, 티켓有→200 |
왜 이 구조가 통제가 되는지?
•
에이전트는 스스로 티켓을 못 만들어. 반드시 매표소(인가 서버) 를 거쳐야 하고, 매표소는 Okta가 운영 → Okta가 "발급할지" 결정.
•
티켓은 1시간이면 만료 → 계속 접근하려면 계속 재발급 필요 → Okta가 언제든 끊을 수 있음.
•
에이전트를 Deactivate하면 매표소가 티켓을 안 줌 → 놀이기구 입장 불가. (=kill switch)