[IAM 가이드] 인증(AuthN)과 인가(AuthZ) 경계 실패 방지와 최신 보안 표준(CAEP, DPoP, ABAC) 도입 전략

 

[IAM 가이드] 인증(AuthN)과 인가(AuthZ) 경계 실패 방지와 최신 보안 표준(CAEP, DPoP, ABAC) 도입 전략

1부: IAM 보안의 근간 해체 - AuthN/AuthZ 경계를 명확히 해야 하는 이유

 

Identity and Access Management (IAM) 아키텍처에서 가장 치명적인 오류는 인증(AuthN)과 인가(AuthZ)의 경계가 모호해지는 것입니다. AuthN이 성공한 후 AuthZ에서 발생하는 정책적 오류는 종종 외부 해킹보다 더 심각한 내부 유출 사고와 법적 리스크를 초래합니다.

 

1.1. IAM의 핵심: AAA 모델의 재정의

 

IAM 시스템의 기본 원칙은 AAA (Authentication, Authorization, Accounting/Auditing) 프레임워크에 기반합니다. 이 세 가지 요소의 논리적 경계를 명확히 이해하는 것이 건전한 보안 아키텍처의 시작입니다.

 

1.1.1. NIST 표준 기반의 AuthN, AuthZ, Auditing 정의

 

인증 (Authentication, AuthN) 은 "당신은 누구입니까(Who are you)?"라는 질문에 답하는 과정입니다. 사용자의 신원(Identity)이 맞음을 증명하며, 비밀번호, OTP 토큰, 생체 인식 등 하나 또는 복합적인 자격 증명(Credentials)을 사용합니다 (MFA).

**인가 (Authorization, AuthZ)**는 인증이 성공한 후, "당신은 무엇을 할 수 있습니까(What are you allowed to do)?"를 결정합니다. 특정 주체(Subject)가 특정 자원 또는 행위에 접근하거나 수행할 권한이 있는지 결정하고 강제합니다.1

**감사 (Accounting/Auditing)**는 사용자의 자원 접근 및 행위 기록을 생성하고 추적하는 과정입니다. 이는 정책 준수 사후 검토 및 보안 사고 발생 시 포렌식 분석을 위한 필수 증거 자료를 제공합니다.1

 

1.1.2. AuthZ: 단일 결정이 아닌 '지속적인 리스크 관리 활동'

 

AuthN과 AuthZ는 순차적(AuthN $\rightarrow$ AuthZ)이지만 기능적 역할은 완전히 분리되어야 합니다. 특히, AuthZ는 단순히 초기 접근 시점의 결정으로 끝나지 않고, 세션이 지속되는 동안 **지속적인 검증(Ongoing Verification)**을 요구하는 시간적 역할을 수행해야 합니다. AuthZ는 세션의 전체 수명 주기 동안 지속되는 연속적인 리스크 관리 활동으로 간주되어야 합니다.

 

1.2. AuthN 성공 후 발생하는 3가지 치명적 AuthZ 오류 시나리오

 

AuthN이 성공했음에도 AuthZ 단계에서 접근이 거부되거나 오류가 발생하는 것은 권한 관리 체계의 정책적 또는 기술적 결함을 드러냅니다.

 

1.2.1. 시나리오 1: Stale Session (취소된 세션의 비정상적 유효성 유지)

 

• 위험 분석: 계정 상태(예: 퇴사, 비밀번호 변경)가 비활성화되었음에도 기존에 발급된 Access Token이나 세션이 유효 기간 만료 전까지 접근을 허용하는 상태입니다.3 공격자가 탈취한 세션을 이용해 시스템에 머무르는 'Dwell Time'을 늘릴 수 있습니다.4
• 기술적 방어책 (Control): 계정 상태 변화 시 중앙 집중식으로 해당 세션 또는 토큰을 즉시 무효화하는 세션 폐기(Session Revocation) 메커니즘을 구현하고, **지속적 접근 평가(Continuous Access Evaluation)**를 수행해야 합니다.

 

1.2.2. 시나리오 2: 권한 과부여 (Over-Privileging) 및 권한 누락

 

• 위험 분석: 업무 수행에 필요한 최소 권한보다 훨씬 많은 권한이 부여되어 **최소 권한 원칙(Principle of Least Privilege, POLP)**을 위반하는 경우입니다.5 협력업체 직원이나 내부자가 과도한 권한을 악용하여 민감 정보를 유출하는 사고(예: 카드사 개인정보 유출)의 주요 원인입니다.6
• 기술적 방어책 (Control): 정적인 RBAC 모델을 지양하고, 접근 요청 시의 컨텍스트(속성)를 기반으로 권한을 동적으로 결정하는 속성 기반 접근 통제(Attribute-Based Access Control, ABAC) 모델로 전환해야 합니다.

 

1.2.3. 시나리오 3: AuthZ 시스템 내부 접근 권한 실패

 

• 기술적 사례: 응용 프로그램이 인증에 성공했으나, 권한 결정을 위해 내부 그룹 멤버십이나 권한 목록을 조회하려 할 때, 인프라 수준의 보안 정책(예: Windows의 Restrict clients allowed to make remote calls to SAM 정책)에 의해 접근이 차단되어 AuthZ가 실패하는 경우입니다.7
• 기술적 방어책 (Control): 전통적인 Kerberos/SAM 기반의 권한 조회 대신, Access Token 내부에 포함된 클레임(Claim)을 이용하여 권한 결정을 내리는 방식으로 전환하여 내부 권한 저장소에 대한 종속성을 줄여야 합니다.

 

1.3. 경계 실패의 치명적 결과: 법적 및 감사 리스크

 

AuthN/AuthZ 경계 실패는 곧 국내 개인정보보호법(PIPA) 및 정보보호 관리체계(ISMS-P) 감사에서 중대한 지적 사항으로 이어집니다.

 

1.3.1. 개인정보보호법상 접근통제 및 내부통제 미흡 사례

 

과거 농협 전산 마비 사고, 카드사 개인정보 유출 사고 등은 협력업체 직원에게 서버 접근 계정과 과도한 권한이 부여되었으나 상세 접근 통제가 이루어지지 않아 발생했습니다.6 이는 기술적 AuthN 우회가 아닌, 정책적 AuthZ 실패가 법적 책임의 근원임을 시사합니다. 핵심 법적 지적 사항은 다음과 같습니다:

1. 권한 관리 미흡: 업무상 필요한 최소한의 권한만을 부여하는 POLP 원칙 위반.6
2. 유출 경로 통제 실패: 엔드포인트 단말에서 외부 저장 매체 접근 통제 등 계층적 보안 체계의 부재.6

 

1.3.2. ISMS-P 감사 지적 리스크 연계 분석

 

권한 과부여나 Stale Session 시나리오는 ISMS-P 인증 기준 중 접근 통제(A.2.6) 영역과 세션 관리(A.9.4.2) 영역의 위반으로 이어집니다.10 ISMS-P 감사 지적은 대부분 권한 관리 프로세스(AuthZ)의 정책적, 절차적 미흡에서 발생하므로, AuthZ 프로세스 강화가 거버넌스 충족의 핵심입니다.

 

2부: 최신 프로토콜 표준 (OIDC, CAEP, DPoP)으로 세션 무결성 확보하기

 

현대 아키텍처에서 인증과 인가는 OAuth 2.0 및 OpenID Connect (OIDC) 토큰을 통해 구현됩니다. 이 토큰들의 역할을 명확히 구분하고 차세대 기술을 통합하는 것이 중요합니다.

 

2.1. OIDC vs. OAuth 2.0: 토큰 역할 분리 해부

2.1.1. ID Token (AuthN): 오직 신원 증명 목적

 

ID Token은 OIDC 표준에 의해 도입되었으며, **사용자의 신원 증명(Authentication)**이 유일한 목적입니다. 클라이언트 애플리케이션(Relying Party)이 사용자가 인증되었음을 확인하는 데 사용됩니다.11

• 오류 방지 핵심: ID Token은 클라이언트 UX를 위한 것이며, Resource Server (API)에 대한 인가(Authorization) 목적으로 사용되어서는 안 됩니다.

 

2.1.2. Access Token (AuthZ): API 접근 권한 위임

 

Access Token은 OAuth 2.0 프레임워크의 핵심이며, 클라이언트가 Resource Owner를 대리하여 **Protected Resource에 접근할 권한(Authorization Grant)**을 위임받았음을 나타냅니다. 이 토큰은 Resource Server (RS)에 접근할 때 제시됩니다.12

 

특징	ID Token (OIDC)	Access Token (OAuth 2.0)
주요 목적	인증 (AuthN): 사용자 신원 증명 및 클라이언트 애플리케이션 로그인	인가 (AuthZ): Protected Resource 접근 권한 위임
표준 근거	OIDC Core Specification	RFC 6749, RFC 9449 (DPoP)
토큰 형식	JWT (JSON Web Token) 필수	임의의 문자열 (Opaque) 또는 JWT 사용 권장
대상 수신자	클라이언트 애플리케이션 (RP)	리소스 서버 (RS/API)
핵심 클레임	iss, sub, aud, exp, auth_time (신원 메타데이터) 11	scope, client_id, exp, jkt (DPoP 시) (권한 및 유효성 정보)
AuthZ 사용 가능 여부	불가 (클라이언트 UX 목적)	가능 (API 접근 권한 부여 목적) 13

 

2.2. 세션 무결성 확보를 위한 차세대 표준 기술

 

토큰 탈취 및 Stale Session 위험에 대응하고 세션의 무결성(Integrity)을 보장하기 위해 CAEP와 DPoP가 도입되었습니다.

 

2.2.1. CAEP (Continuous Access Evaluation Protocol)의 작동 원리

 

CAEP는 세션 유효성을 지속적으로 평가하여 Stale Session 문제를 해결하는 프로토콜 표준입니다.14 로그인 시점의 정적 검사 대신, CAEP는 사용자 세션 수명 주기 내내 접근 권한이 적절한지 실시간으로 재평가합니다.14

• 작동 방식: Identity Provider (IdP)가 계정 상태 변경(예: 비밀번호 재설정, 직무 변경)과 같은 중요한 보안 이벤트(Security Events)를 감지하여, **Shared Signals Framework (SSF)**를 통해 SET (Security Event Token) 형식으로 Resource Server (Receiver)에 실시간 푸시합니다.5
• Zero Trust 강화: CAEP는 실시간 컨텍스트 변화를 반영하여 위험 기반 인증(RBA) 및 Just-in-Time (JIT) 접근을 강제하며, session-revoked 이벤트 19 수신 시 즉시 세션을 종료하여 공격자의 Dwell Time을 최소화합니다.4

 

2.2.2. DPoP (Demonstration of Proof-of-Possession)의 작동 원리

 

DPoP는 Access Token의 탈취 위험을 방지하기 위해 토큰을 특정 클라이언트에게 Sender-Constraining하는 애플리케이션 계층 메커니즘입니다.9 Bearer Token과 달리, 토큰에 바인딩된 개인 키(Private Key)의 소유 증명(Proof-of-Possession)을 요구합니다.9

• 토큰 바인딩: 인증 서버(AS)는 클라이언트의 Public Key 썸프린트(JWK Thumbprint)를 Access Token 내부의 cnf 클레임(Confirmation Claim)에 바인딩하여 토큰을 발급합니다.21
• 소유 증명 및 검증: Resource Server는 클라이언트가 Access Token과 함께 Private Key로 서명된 DPoP Proof JWT를 제시하면, 다음 세 가지를 검증합니다 9: (1) DPoP Proof JWT의 서명 유효성, (2) DPoP Proof JWT의 Public Key와 Access Token cnf 클레임의 일치 여부, (3) DPoP Proof JWT 내의 HTTP 메서드와 URI 일치 여부.

 

2.2.3. 기존 IAM 솔루션에의 통합 방안

 

CAEP와 DPoP는 상호 보완적으로 작용하여 Bearer Token 기반 IAM의 취약점을 보강합니다.22

1. CAEP/SSF 통합: 기존 IdP는 CAEP/SSF Transmitter 기능을 활성화하여, 중요한 보안 이벤트를 SSF 표준(SET)에 맞춰 실시간으로 발행해야 합니다.17 API 게이트웨이 및 Microservice와 같은 Relying Party는 Receiver 역할을 수행하여 SSF 스트림을 구독하고 강제적인 세션 폐기(Forced Revocation)를 실행해야 합니다.19
2. DPoP 통합: 인증 서버(AS)는 Access Token에 cnf 클레임을 추가하는 로직을 구현하고 21, Resource Server (RS)는 모든 API 접근 요청에 대해 DPoP 헤더를 필수적으로 검증하여 토큰의 정당한 소유를 확인해야 합니다.9

 

2.3. SAML/OIDC 실무 선택 매트릭스

 

SSO 프로토콜 선택은 아키텍처의 미래 방향을 결정합니다. OIDC는 JSON/JWT 기반의 경량화된 구조로 모바일, SPA, 클라우드 네이티브 백엔드에 적합하며, 구현 복잡성이 낮아 빠른 배포가 용이합니다. SAML은 XML 기반으로 무겁지만, 레거시 웹 애플리케이션이나 VDI 환경에 강력합니다.

Table 2.3.1.1. SAML vs. OIDC 실무 선택 의사결정 매트릭스

 

구분 기준	SAML 2.0 (Security Assertion Markup Language)	OpenID Connect (OIDC)
프로토콜 기반	독립적인 XML 기반 표준	OAuth 2.0 기반 확장 (API 중심)
데이터 형식	XML Assertion (Verbose) 23	JSON/JWT (Lightweight)
기술적 복잡성	높음 (XML 스키마, 서명, 메타데이터 관리) 22	낮음 (JSON 네이티브, RESTful)
성능 (Performance)	상대적으로 느림 (페이로드 크기)	빠름 (JWT 기반 경량화)
모바일/Native App 지원	취약 (브라우저 리다이렉트 의존)	우수 (RESTful API, JSON 기반)
클라우드/API 게이트웨이 적합성	보통	우수 (Cloud Native, Microservices 적합) 20
주요 사용 사례	엔터프라이즈 레거시 웹 SSO, VDI 21	모바일, SPA, API 기반 서비스 22

 

3부: 거버넌스 충족 및 실무 위험 대응 전략 (ISMS-P, ABAC)

 

AuthN/AuthZ 경계 실패는 IT 운영 리스크를 넘어 법규 위반 및 거버넌스 실패로 직결됩니다. CISO 및 IAM팀은 감사 지적을 피하기 위한 기술적 대응책을 마련해야 합니다.

 

3.1. ISMS-P 감사 리스크 관리 및 필수 구현 기능

 

AuthN/AuthZ 경계 실패와 관련된 ISMS-P 핵심 통제 항목과 이를 해결하기 위한 IAM 시스템의 필수 구현 기능은 다음과 같습니다.

Table 3.1.1.1. AuthN/AuthZ 경계 실패 관련 ISMS-P 통제 항목 및 해결책

 

ISMS-P 통제 항목	A.9.4.2 세션 관리	A.2.6.2 정보시스템 접근	A.2.6.3 응용프로그램 접근
경계 실패 위험	Stale Session 발생, 비인가 접속 지속 3	권한 취소 미반영 계정의 서버 접근 10	권한 과부여, 최소 권한 원칙 위반 10
IAM 필수 구현 기능	CAEP/SSF 기반 지속적 평가 및 중앙 집중식 세션 즉시 폐기 14	DPoP를 통한 Access Token의 클라이언트 바인딩 강제 9	ABAC 기반 동적 정책 엔진 및 AuthN 클레임 활용

 

3.1.1. A.9.4.2 세션 관리 (Stale Session 방지)

 

Stale Session 위험에 대응하기 위해 IAM 솔루션은 CAEP/SSF 표준을 통합해야 합니다.14 이는 IdP가 사용자 위험 신호 변화를 감지하고 SSF를 통해 Resource Server에 실시간 전달하여, 유효성 재평가 및 강제적 세션 폐기(Forced Revocation)를 유도함으로써 ISMS-P의 세션 관리 항목을 충족시킵니다.15

 

3.1.2. A.2.6.2 정보시스템 접근 (토큰 무결성 확보)

 

Bearer Token 탈취로 인한 비인가 접근 위험을 최소화하기 위해, IAM 시스템은 DPoP를 기술적 방어책으로 강제해야 합니다.9 DPoP는 Access Token이 특정 클라이언트 세션에 바인딩되도록 보장하여, 토큰이 탈취되더라도 공격자가 Private Key 없이는 서버 접근을 시도할 수 없도록 합니다.9

 

3.1.3. A.2.6.3 응용프로그램 접근 (최소 권한 원칙 강제)

 

권한 과부여로 인한 내부자 유출 리스크에 대응하기 위해, IAM 시스템은 ABAC 기반의 인가 정책 엔진을 필수적으로 구현해야 합니다. ABAC는 사용자의 속성, 자원의 속성, 요청 행위, 환경적 컨텍스트를 종합적으로 활용하여 POLP를 동적으로 강제합니다.16

 

3.2. ABAC 정책 구현: AuthN 정보를 인가 결정에 활용하기

 

ABAC (Attribute-Based Access Control)는 AuthN 정보를 인가 결정에 활용함으로써 AuthN/AuthZ 경계를 논리적으로 연결합니다. ABAC 정책은 주체, 자원, 행위, 환경의 4가지 요소에 대한 속성(Attribute)을 정의하고, 이 속성들이 모두 만족될 때만 접근을 허용합니다.16

 

3.2.1. ABAC의 4대 요소 및 AuthN 클레임 활용 전략

 

1. 주체 속성 (Subject Attributes): OIDC ID Token 또는 Access Token 클레임에서 파생됩니다 (예: department, job_title, clearance_level).17
2. 자원 속성 (Resource Attributes): 접근 대상 자원에 대한 속성 (예: sensitivity_level, resource_type).
3. 행위 속성 (Action Attributes): 주체가 자원에 대해 수행하려는 동작 (예: READ, WRITE, DELETE).
4. 환경 속성 (Environment Attributes): 접근 요청 시점의 컨텍스트 정보 (예: access_time, network_location, device_status).10

 

3.2.2. AuthN 정보를 활용하는 ABAC 기반 인가 정책 Pseudocode 예시

 

다음 Pseudocode는 Subject Attributes (AuthN 클레임)와 Environment Attributes를 결합하여 인가 결정을 내리는 ABAC의 동적 특성을 보여줍니다.

Pseudocode: 민감 금융 데이터 접근 정책 (Policy_Sensitive_Financial_Data)

 

코드 스니펫

Policy Decision Point (PDP): Evaluate_Access_Request(Subject, Resource, Action, Environment)

// 정책 1: 기본 READ 접근 권한 (Finance Analyst/Manager, 내부 네트워크, 업무 시간)
IF Subject.department == "Finance"
    AND Subject.job_title IN ["Analyst", "Manager"]
    AND Resource.sensitivity_level == "Confidential Financial Report"
    AND Action == "READ"

// 환경적 통제 조건 추가
    AND Environment.network_trust_level == "Internal-Corporate-Network"
    AND Environment.access_time BETWEEN 09:00 AND 18:00 LocalTime
    AND Environment.device_status == "Corporate-Managed"

THEN
    GRANT ACCESS
    LOG_AUDIT_TRAIL("Access granted based on ABAC Policy: Finance/Internal")

// 정책 2: 민감 데이터 MODIFY에 대한 강화된 통제 (Director급, 물리적 HQ, 고강도 MFA 요구)
ELSE IF Subject.department == "Finance"
    AND Subject.job_title == "Director"
    AND Resource.sensitivity_level == "Confidential Financial Report"
    AND Action == "MODIFY"

// 최고 수준의 환경 및 인증 조건 요구
    AND Environment.network_location == "Physical_HQ_Location"
    AND Environment.MFA_strength == "High_Assurance_FIDO2"

THEN
    GRANT ACCESS
    LOG_SECURITY_ACTION("High-Risk Access granted, MFA strength checked.")

ELSE
    DENY ACCESS
    LOG_SECURITY_INCIDENT("ABAC Policy Denied: Insufficient Attributes or Context")

END IF

 

결론 및 권고 사항

 

AuthN과 AuthZ의 경계 명확화는 단순한 이론적 구분이 아닌, 실무적인 보안 아키텍처 및 거버넌스 준수를 위한 필수 전제 조건입니다.

IAM 전문가들은 다음의 세 가지 핵심 영역에 집중하여 시스템을 현대화해야 합니다.

1. AuthZ의 지속성 확보: CAEP (Continuous Access Evaluation Protocol)와 SSF (Shared Signals Framework)를 도입하여 실시간으로 권한 유효성을 평가하고 세션을 폐기하는 시스템을 구축해야 합니다. 이는 ISMS-P A.9.4.2 세션 관리 항목을 동적 리스크 반응 시스템으로 업그레이드하는 핵심 전략입니다.
2. 토큰 무결성 강화: DPoP (Demonstration of Proof-of-Possession) 표준을 Access Token 발행 및 검증 과정에 필수로 적용하여 Bearer Token 탈취 위험을 해소해야 합니다.
3. POLP의 기술적 강제: ABAC (Attribute-Based Access Control) 정책 엔진을 도입하여 AuthN 클레임과 요청 시점의 환경 속성을 통합하고, 권한 결정을 고도로 세분화하고 동적으로 수행함으로써 PIPA 및 ISMS-P A.2.6.3 접근 통제 요구사항을 충족시켜야 합니다.

참고 자료

1. What Is Authentication, Authorization, And Accounting (AAA) Security? - Fortinet, 11월 12, 2025에 액세스, https://www.fortinet.com/resources/cyberglossary/aaa-security
2. Authn vs. authz: how are they different? - Fastly, 11월 12, 2025에 액세스, https://www.fastly.com/learning/security/authn-vs-authz
3. Session revocation explained: Protect your users, systems, and AI agents - WorkOS, 11월 12, 2025에 액세스, https://workos.com/blog/session-revocation-sign-out-everywhere
4. What is Continuous Access Evaluation Profile (CAEP)? - CrowdStrike, 11월 12, 2025에 액세스, https://www.crowdstrike.com/en-us/cybersecurity-101/identity-protection/continuous-access-evaluation-profile-caep/
5. 신원 접근 관리(IAM)란 무엇인가?" - SentinelOne, 11월 12, 2025에 액세스, https://www.sentinelone.com/ko/cybersecurity-101/identity-security/what-is-identity-access-management-iam/
6. 개인정보유출 대응, 시작은 엔드포인트 보안 - 디지털데일리, 11월 12, 2025에 액세스, https://m.ddaily.co.kr/page/view/2014042111385987758
7. Access checks fail because of AuthZ - Windows Server - Microsoft Learn, 11월 12, 2025에 액세스, https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/authz-fails-access-denied-error-application-access-check
8. OpenID Shared Signals Framework Specification 1.0, 11월 12, 2025에 액세스, https://openid.net/specs/openid-sharedsignals-framework-1_0.html
9. RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP) - IETF Datatracker, 11월 12, 2025에 액세스, https://datatracker.ietf.org/doc/html/rfc9449
10. ISMS-P 항목 정리 1 - MSS - 티스토리, 11월 12, 2025에 액세스, https://mokpo.tistory.com/588
11. ID tokens in the Microsoft identity platform, 11월 12, 2025에 액세스, https://learn.microsoft.com/en-us/entra/identity-platform/id-tokens
12. RFC 6749 - The OAuth 2.0 Authorization Framework - IETF Datatracker, 11월 12, 2025에 액세스, https://datatracker.ietf.org/doc/html/rfc6749
13. Id Tokens vs Access Tokens: A Simple Guide with Examples | by Osama HaiDer - Medium, 11월 12, 2025에 액세스, https://osamadev.medium.com/id-tokens-vs-access-tokens-a-simple-guide-with-examples-ab7a9d5e3301
14. What is Continuous Access Evaluation Protocol (CAEP)? 2025 Overview - Strata Identity, 11월 12, 2025에 액세스, https://www.strata.io/glossary/caep-continuous-access-evaluation-protocol/
15. Google Workspace Shared Signals Framework (SSF) Integration Guide Closed BETA, 11월 12, 2025에 액세스, https://developers.google.com/workspace/shared-signals/api/ssf-api
16. Attribute Based Access Control (ABAC) - A Complete Guide | Zluri, 11월 12, 2025에 액세스, https://www.zluri.com/blog/attribute-based-access-control
17. Shared Signals Working Group - OpenID Foundation, 11월 12, 2025에 액세스, https://openid.net/wg/sharedsignals/
18. Demonstrating Proof of Possession Overview - Curity, 11월 12, 2025에 액세스, https://curity.io/resources/learn/dpop-overview/
19. 11월 12, 2025에 액세스, https://datatracker.ietf.org/doc/html/rfc6749#:~:text=Access%20tokens%20are%20issued%20to,hosted%20by%20the%20resource%20server.
20. SAML vs. OIDC: Deepdive into the standard authentication protocols - Scalekit, 11월 12, 2025에 액세스, https://www.scalekit.com/blog/saml-vs-oidc
21. What is SAML vs OAuth? Key Differences and Comparisons - Fortinet, 11월 12, 2025에 액세스, https://www.fortinet.com/resources/cyberglossary/saml-vs-oauth
22. The Difference Between SAML vs OIDC - StrongDM, 11월 12, 2025에 액세스, https://www.strongdm.com/blog/oidc-vs-saml
23. OIDC vs SAML: A Comprehensive Technical Comparison - Security Boulevard, 11월 12, 2025에 액세스, https://securityboulevard.com/2024/07/oidc-vs-saml-a-comprehensive-technical-comparison/
24. What is Attribute-Based Access Control (ABAC)? - CrowdStrike, 11월 12, 2025에 액세스, https://www.crowdstrike.com/en-us/cybersecurity-101/identity-protection/attribute-based-access-control-abac/
25. Understanding RBAC, PBAC, and ABAC: Access Control Explained - Ping Identity, 11월 12, 2025에 액세스, https://www.pingidentity.com/en/resources/identity-fundamentals/authorization/authorization-methods.html