concepts

Okta Concepts

Okta 개발자 문서의 «Concepts» 페이지는 Okta의 API와 아키텍처 기본 개념을 정리한 시작점이에요. 이 문서는 Okta Identity Engine 개요, OAuth 2.0과 OpenID Connect, Okta 배포 모델, IAM(신원 및 접근 관리), 정책(Policies), 멀티테넌시(multi-tenancy) 같은 핵심 개념들을 한데 모아 둡니다. Okta가 어떻게 인증과 인가, 사용자/그룹 관리, 액세스 제어를 처리하는지 파악하고 싶다면 이 페이지가 가장 좋은 출발점이 돼요.

출처: 문서

본문

OAuth 2.0과 OpenID Connect (OIDC)

OAuth 2.0과 OpenID Connect(OIDC)는 사용자 인증과 인가를 위한 업계 표준 프로토콜이에요. Okta의 신원 솔루션은 이 표준들을 기반으로 합니다. 두 프로토콜은 서로 보완적이에요. 서버가 사용자를 인증하고, 그 다음 사용자에게 리소스에 접근할 권한을 부여하는 방식을 정의하거든요.

  • OAuth 2.0은 웹 앱·네이티브 앱·API 서비스 같은 보호된 리소스에 대한 접근을 제어하고 위임(인가)합니다. 범위 제한된 액세스 토큰(scoped access token)을 통해 API 보안을 제공해요.
  • OIDC는 OAuth 2.0에 사용자 인증과 Single Sign-On(SSO) 기능을 더해서 확장한 표준이에요. 최종 사용자에 대한 인증 정보를 조회하고 저장할 수 있게 해주며, 앱이 사용자 프로필 정보에 접근할 수 있도록 몇몇 OAuth 2.0 스코프도 정의해요.

OAuth 2.0 명세에는 네 가지 중요한 역할이 있어요:

  • Client: 어떤 데이터에 접근하려는 앱.
  • Resource server: 클라이언트가 접근하려는 데이터를 저장하는 API나 앱.
  • Resource owner: 리소스 서버에 있는 데이터의 소유자. 예를 들어 당신은 당신의 Facebook 프로필의 소유자예요.
  • Authorization server: 접근을 관리하고 액세스 토큰을 발급하는 서버. Okta 입장에서는 Okta가 바로 authorization server예요.

그 외에 중요한 용어로는 OAuth 2.0 grant(클라이언트가 사용자로부터 받은 인가. Authorization Code, Client Credentials 같은 예가 있음), access token(grant의 대가로 Okta가 발급하는 토큰), refresh token(액세스 토큰이 만료됐을 때 새 액세스 토큰과 교환하는 선택적 토큰)이 있어요.

보통의 Authorization Code flow는 이렇게 동작해요:

  1. 클라이언트가 리소스 소유자(보통 사용자)에게 인가를 요청해요.
  2. 소유자가 인가하면, 클라이언트는 인가 grant를 authorization server(여기서는 Okta)에 전달해요.
  3. grant가 유효하면 authorization server가 액세스 토큰을 반환하고, 때에 따라 refresh/ID 토큰도 함께 반환해요.
  4. 클라이언트는 이제 그 액세스 토큰으로 리소스 서버에 접근해요.

OAuth 2.0과 OIDC의 핵심에는 authorization server가 있어요. authorization server는 단순히 OAuth 2.0 토큰을 만드는 엔진입니다. 각각 고유한 issuer URI와 자체 서명 키를 가져서 보안 도메인 간 경계를 제대로 유지해요. authorization server는 동시에 OIDC provider 역할을 하기도 하는데, 그러면 authorization server 엔드포인트에서 액세스 토큰뿐 아니라 ID token도 함께 요청할 수 있어요.

OIDC는 OAuth 2.0 위에 쌓인 인증 표준이에요. OAuth 2.0의 액세스/리프레시 토큰과 짝을 이루는 ID token 유형을 정의하고, 스코프·엔드포인트 발견·클라이언트 동적 등록처럼 OAuth 2.0이 선택에 맡겨둔 영역도 표준화해요. OIDC 흐름 전반부는 OAuth 2.0과 동일하며, 핵심 차이는 OIDC 흐름이 ID token까지 결과물로 낸다는 점이에요.

어떤 OAuth 2.0 flow를 쓸까는 만들고 있는 앱 유형과 클라이언트 성격에 따라 달라져요.

  • 서버사이드(웹), SPA, 네이티브 앱 → Authorization Code with PKCE 또는 Interaction Code(Identity Engine 전용). 액세스·ID 토큰 모두 지원.
  • 신뢰할 수 있는(trusted) 클라이언트 → Interaction Code.
  • 서비스/머신 간(M2M) 통신 → Client Credentials (액세스 토큰만, ID 토큰 없음).
  • 리다이렉트 모델 사용 시 → SPA·네이티브 앱은 Authorization Code with PKCE.
  • 임베디드(embedded) 모델로 앱이 인증 흐름을 직접 호스팅할 때 → Interaction Code.
  • 고신뢰(high-trust) 앱이고 다른 flow가 불가능한 경우에만 → Resource Owner Password flow. 다만 이 flow는 다요소 인증(MFA)과 함께 쓸 수 없어요.

PKCE는 원래 모바일 앱의 Authorization Code flow를 보호하려고 설계된 확장이에요. 인증 코드 주입(code injection)을 막고 흐름을 안전하게 유지하는 능력 덕분에 모든 종류의 OAuth 클라이언트에 최적이에요. Okta는 가능하면 Authorization Code flow with PKCE를 쓰라고 권장해요. 앱이 암호학적으로 랜덤한 문자열 code verifier를 만들고, 이를 해시해 code challenge를 만든 뒤 인증 코드 요청과 함께 전달하는 방식이에요. 나중에 앱이 인증 코드와 code verifier를 보내 액세스 토큰을 요청하면, authorization server가 verifier로 challenge를 다시 계산해 처음과 일치하는지 비교해서 같은 클라이언트가 보낸 요청임을 확인해요.

멀티테넌시 (Multi-tenancy)

다양한 유형의 사용자를 관리해야 하는 조직은 Okta의 멀티테넌트 솔루션을 고려할 만해요. 테넌트(tenant)란 한 집단의 사용자를 지원하는 소프트웨어와 인프라의 단일 인스턴스를 뜻해요. 테넌트는 조직과 접점을 가지는 어떤 주체(직원, 고객, 파트너 등)를 대표할 수 있어요. 신원 관리 맥락에서 테넌트는 다른 테넌트와 분리된 고립된 데이터의 섬으로 볼 수 있어요. 각 테넌트는 자신만의 보안 정책, 사용자 등록 설정, 사용자 그룹, 역할, 앱 접근을 결정하는 규칙을 가져요.

Okta에서 테넌트는 Org로 표현돼요. 각 org는 자신의 사용자와 그룹, 앱을 독립적으로 관리하는 고립된 컨테이너예요. Okta에서 신원(identity)은 org에 한정되어 있고, Okta 전체에 걸쳐 전역적으로 고유하지는 않아요. 예를 들어 [email protected]이라는 이메일이 https://company1.okta.com과 https://company2.okta.com 두 org에 서로 다른 프로필 데이터로 등록될 수 있어요. 여러 테넌트를 서비스하는 앱을 만들 때는 어떤 org가 해당 사용자를 인증했는지 추적해야 하며, 프로필 데이터가 org 간에 일관적이라고 가정하면 안 돼요.

SSO 앱 통합은 기본적으로 멀티테넌트예요. 각 고객(SSO 앱을 배포하는 org)은 별도의 Okta org로 운영되고, 각 org가 한 테넌트가 돼요. org는 해당 고객 사용자의 identity provider(IdP) 역할을 해요. OIDC 통합에서는 org가 authorization server로, SAML 통합에서는 org가 IdP로 동작해요. 각 org가 자신의 사용자·정책·앱 접근을 독립적으로 관리하기 때문에, 단일 앱 통합이 여러 고객을 서비스해도 서로의 데이터나 설정에 영향을 주지 않아요.

OIDC 통합의 경우 Okta는 로컬 인증정보(local credential) 시스템을 써요. 고객이 자기 org에 통합을 추가하면 앱에 대한 고유한 OIDC 인증정보 세트를 얻어요. 즉 고객 org 안의 앱 통합 인스턴스마다 별도의 클라이언트 인증정보를 가져요. 이는 전역 인증정보(같은 앱이 모든 org에서 같은 고객 인증정보를 공유)를 쓰는 다른 IdP와 다른 점이에요. 따라서 앱 통합 인스턴스별 클라이언트 인증정보를 각각 추적해야 해요. 예를 들어 앱 통합이 10개 고객 org에 추가됐는데, 7곳은 인스턴스 1개, 3곳은 각각 2개 인스턴스를 만들었다면 총 13벌의 클라이언트 인증정보를 추적해야 해요.

조직이 테넌트를 여럿 두는 이유는 다양해요: 내부 직원과 외부 고객의 사용자 관리/앱 접근을 분리하거나, 규정과 데이터 거주지(residency) 요건 때문에 특정 지역에 고객 데이터를 저장하거나, 브랜딩·온보딩 같은 고유 요건을 충족하거나, 사용자 기반이 큰 조직의 격리·성능·확장성을 높이려는 경우 등이에요. 테넌트는 개별 고객, 사업체, 직원, 계약자, 외부 파트너 등으로 구성될 수 있어요.

Okta는 네 가지 주요 멀티테넌시 구성을 제공해요:

  1. Universal Directory(UD)를 쓰는 단일 org에 테넌트 호스팅 — 모든 테넌트를 한 org에 두고, org 안에 별도 테넌트 엔티티가 없으므로 사용자와 사용자 그룹으로 테넌트를 추상화해요. 비용이 우선일 때, 사용자가 모든 앱의 단일 버전을 쓸 때, 자체등록·브랜딩·온보딩이 모두 동일할 때, 데이터 거주지 요건이 없을 때 적합해요. 테넌트는 보통 그룹으로 만들어져요. 그룹(또는 그룹 모음)이 테넌트의 사용자를 나타내고, 그 그룹을 앱에 할당하면 그 그룹 안의 모든 사용자에게 앱 접근이 부여돼요.
  2. 별도 org에 테넌트 호스팅 (예: hub-and-spoke)
  3. 혼합 — 단일 org와 별도 org에 테넌트를 함께 두기
  4. UD를 쓰지 않는 단일 org에 테넌트 호스팅

단일 org 구성에서 권장하는 전략은 점점 더 많은 권한을 가진 사용자 계층을 만들 수 있도록 **사용자 유형(user types)**을 만드는 거예요. 예를 들어 User(테넌트 일반 사용자), Admin User, Super User(Admin of Admins) 세 유형을 정의할 수 있어요. 일반 사용자는 할당된 제품과 앱에 접근할 수 있고, 설정에 따라 비밀번호 변경이나 MFA 등록 같은 자신의 프로필을 직접 관리할 수도 있어요.

사용자/그룹과 IAM

**IAM(Identity and Access Management)**은 "올바른 사람이 올바른 서비스에 접근하게" 하는 인증(authentication)과 인가(authorization)의 핵심 개념이에요. IAM은 두 가지 방식으로 서비스를 보호해요. 첫째, 사용자가 로그인할 때 그 신원을 검증하고, 둘째, 사용자가 권한이 있는 네트워크와 서비스의 일부에만 접근하게 해요.

IAM의 고수준 설계 유형에는 **워크포스 신원(Workforce identity)**과 **고객 신원(Customer Identity, CIAM)**이 있어요.

  • **워크포스 신원(WF)**은 직원과 계약자의 조직 앱·리소스 접근을 관리해요. 주요 목표는 위험 관리이며, IT 팀이 사용자 신원을 할당하고 사용 사례는 보통 관리자 중심이에요(예: 앱을 SSO에 통합해 접근 통제).
  • **고객 신원(CIAM)**은 고객·파트너 등 외부 접근을 WF에 더해 관리해요. 사용자 편의가 중요하고, 고객은 보통 스스로 신원을 만들고 여러 위치·플랫폼에서 로그인하며 여러 신원을 가질 수 있어요(예: 브랜드화된 등록/로그인 흐름 구축).

IAM 솔루션의 기능은 사용자 경험, 보안, 인프라 세 영역으로 나눌 수 있어요. 보안 측면에서 중요한 기능에는 사용자 저장·비밀번호 관리, 다요소 인증(MFA), DDoS 보호, 규정 준수(예: HIPAA, GDPR), 그리고 **데이터 접근 제어(data access control)**가 있어요. 데이터 접근 제어는 정책·사용자 인증·인가나 다른 데이터에 기반해 사용자의 앱·리소스 접근 요청을 허용하거나 거부하는 방식으로, 앱 개발자는 코드 곳곳에 접근 제어 검사를 심어 요구사항을 강제해요.

IAM 솔루션을 설계할 때는 다음 영역을 고려해야 해요:

  • 신원 관리(Identity management): 인가된 개인·사업체·기기·앱·기타 리소스와 그 속성·정책을 식별하는 데이터를 저장·관리해요. 사용자 인증·인가·접근 제어의 핵심 데이터 원천이 돼요.
  • 인증(Authentication): 사용자 로그인 자격증명이 정당하고 소유자 본인이 쓰는 것인지 검증해요.
  • 인가(Authorization): 사용자가 접근할 수 있는 리소스와 그 리소스로 수행할 수 있는 기능을 정의해요.
  • 접근 제어(Access control): 보호된 리소스에 대한 개별 접근 요청을 리소스·인증 여부·인가·정책 등에 따라 허용하거나 거부해요. 접근 제어는 인가의 일부예요.

이 모든 기능은 높은 신뢰성·가용성·보안을 갖춰야 해요.

정책 (Policies) — 액세스 제어

**정책(Policies)**은 앱과 API에 대한 접근을 관리할 수 있게 해주는 규칙 집합이에요. 사용자·그룹 구성원 자격, 기기, 위치, 시간 같은 다양한 조건에 따라 접근을 제한할 수 있고, 민감한 앱에 접근할 때는 모바일 푸시 알림이나 SMS 일회용 코드 같은 추가 인증 단계를 요구할 수도 있어요. 정책은 요청이 발생할 때 평가되며, 규칙들이 요청 허용/거부를 결정합니다. 정책은 Okta 안에 JSON 문서로 저장돼요.

정책 사용 사례는 다양해요:

  • 조건을 이용한 복잡한 로직 기반 인가 규칙 만들기
  • 사용자가 특정 앱에 접근하기 전에 수행해야 할 추가 인증 단계 결정
  • 허용 사용자 목록을 유지하고 여러 조건에 따라 접근 거부
  • inline hooks를 통해 액세스 토큰의 스코프를 바꾸고 ID token에 클레임 추가
  • 사용자가 로그인할 때 API로 실시간으로 다른 시스템에 알림
  • 토큰 스코프로 외부 DB·API에서 사용자 정보를 조회해 사용자 프로필에 추가
  • 엔티티 리스크나 세션 컨텍스트 변화 같은 신원 위협 모니터링
  • 인증기 등록, 비밀번호 재설정, 계정 잠금 해제 시 인증 요구사항 정의

누가 앱에 접근하는지는 전역 세션 정책(global session policy)이 통제해요. 이 정책은 사용자가 Okta에 로그인하는 방식(사용자 식별)과 세션 길이를 지정해요. 예를 들어 기업 네트워크 내부 사용자만 접근하도록 1차·2차 인증 요소 조건을 설정한 규칙을 추가할 수 있어요.

사용자가 앱에 어떻게 접근하는지는 각 앱의 **앱 로그인 정책(app sign-in policy)**이 결정해요. 이 정책은 사용자가 앱에 접근하기 전에 수행해야 할 추가 인증 수준을 정해요. 예를 들어 앱에 할당된 그룹에 60분 후 재인증을 요구하는 규칙을 추가할 수 있어요. 비밀번호 정책은 비밀번호 길이·복잡성 요구사항과 변경 주기를 정의하고, **인증기 등록 정책(authenticator enrollment policy)**으로는 첫 로그인 시 인증 요소 등록을 요구하거나 특정 조건에서 추가 인증 챌린지를 트리거할 수 있어요.

이처럼 Okta는 OAuth 2.0/OIDC라는 표준 인증·인가 기반 위에, org 단위의 멀티테넌시와 사용자·그룹, 그리고 정책 기반의 액세스 제어를 결합해서 신원 관리를 제공합니다.

더 알아보기 (Learn more)