Identity Protocols
서로 다른 하드웨어 시스템 간에 신원 정보를 물리적으로 교환하고, 신뢰를 전이시키기 위한 OAuth2, OIDC, SAML과 같은 글로벌 통신 규약의 수리적 수순을 다룹니다.
sys.entry
M
Me
hyunyoun's Blog
posts7 min read
1. Overview
ID 프로토콜(Identity Protocols, IDP)은 고립된 서비스들이 신뢰할 수 있는 제3의 물리 기관을 통해 사용자의 신분을 수리적으로 인정받고, 서비스 간 권한을 안전하게 위임하는 '신뢰 연결 물리학'입니다.
학습자는 웹과 모바일의 표준 인가 프로토콜인 OAuth 2.0과, 그 위에 신원 정보 레이어를 얹은 **OpenID Connect(OIDC)**의 물리적 핸드쉐이크 과정을 배웁니다. 특히, 기업 환경에서 널리 쓰이는 XML 기반의 SAML 프로토콜의 수리적 구조와 보안 특성을 익힙니다. 이를 통해 '구글로 로그인'과 같은 소셜 인증부터 대기업의 통합 신원 인식 환경까지, 국경 없는 하드웨어 신뢰망을 구축하는 하이엔드 프로토콜 공학 역량을 확보합니다.
2. Scope & Boundaries
In-Scope
- OAuth 2.0 Flows: Authorization Code, Client Credentials 등의 물리적 메시지 교환 수순
- OIDC Mechanics: ID Token, UserInfo Endpoint, Discovery Doc의 수리적 결합
- SAML 2.0 Basics: Assertion, SP/IdP 간의 XML 기반 물리적 신뢰 전이
- Token Handling: Access/Refresh/ID Token의 수리적 수명 관리 및 갱신 기제
- Claims & Scopes: 전달되는 신원 정보의 범위와 수치적 제약 설정
Out-of-Scope
- 사용자에게 아이디/패스워드를 입력받는 UI 처리 상세 (10-04-01 AMN 영역에서 분담)
- 토큰 내부 암호화 알고리즘(RSA, HMAC)의 수학적 상세 (10-01-01 SAA 영역에서 분담)
Boundaries
- IDP vs. AMN: AMN(10-04-01)이 '지문을 찍는 행위 자체'에 집중한다면, IDP는 '그 지문이 찍혔다는 사실을 다른 하드웨어 서버에 수리적으로 어떻게 보고할 것인가'라는 소통의 물리학에 집중하여 구분합니다.
3. Counterexample
- 단순히 "로그인 연동하기"라 설명하는 것은 IDP 학습이 아닙니다. 왜 Authorization Code Flow에서 'PKCE'라는 물리적 장치가 포함되지 않으면 모바일 하드웨어 환경에서 토큰이 수리 탈취될 수 있는지 증명할 수 있어야 하며, SAML 답변 메시지의 디지털 서명을 검증하지 않고 신뢰했을 때 발생하는 'XML Signature Wrapping' 공격의 물리적 위험성을 논증하지 못한다면 ID 프로토콜의 본질을 이해하지 못한 것입니다.
4. Prerequisites
- Web Protocols & API Paradigms (Basic): 08-03-XX의 HTTP 리다이렉션, 헤더, 상태 코드 이해가 필수입니다.
- Symmetric & Asymmetric Algorithms (Basic): 10-01-01의 서명 및 공개키 인증 원리 이해가 필수입니다.
5. Learning Map
- The Messenger of Trust: 내가 직접 신분증을 확인하지 않고, 믿을 만한 형님(IdP)의 보증을 받는 물리 논리를 이해합니다.
- Standard Languages: OAuth2와 SAML이라는 전 세계 공용 보안 언어의 수리적 문법을 익힙니다.
- The Layer of Identity: 단순히 문만 열어주는 것을 넘어, "이 사람의 이름은 무엇인가"라는 정보(OIDC)를 물리적으로 나릅니다.
- Federated World: 한 번의 로그인으로 수만 개의 연결된 하드웨어 세상을 자유롭게 넘나드는 하이엔드 신뢰망을 완성합니다.
6. Learning Topics
Basic
Core: OAuth 2.0의 기초와 인가 흐름 (Delegation Physics)
- Why to Learn: 내 비밀번호를 앱에 알려주지 않고도, 그 앱이 내 대신 사진을 올리거나 메일을 읽게 하기 위해서입니다.
- What to Learn:
- Roles: Resource Owner, Client, Auth Server, Resource Server의 물리적 배령
- Authorization Code Flow: 가장 안전한 3자 간의 수리적 토큰 교환 수순
- Access Token: 하드웨어 문을 열 때 보여주는 짧은 수명의 수리적 패스
- How to Learn:
- 구글이나 카카오 개발자 센터에서 앱을 등록하고, 브라우저 주소창에 나타나는
code값을 수치화하여 토큰으로 바꾸는 실습 - 토큰이 만료되었을 때
Refresh Token을 써서 하드웨어가 자동으로 새로운 권한을 얻는 물리 루프 확인
- 구글이나 카카오 개발자 센터에서 앱을 등록하고, 브라우저 주소창에 나타나는
- Implement: OAuth2 서버와 통신하여
auth_code를 받아오는 기초TokenRequester
Recommended
Core: OpenID Connect와 신원 증명 (Identity Physics)
- Why to Learn: 앱 서비스가 "이 사용자는 정말 이메일이 @gmail.com 인 사람이다"라는 사실을 수리적으로 확신하게 하기 위함입니다.
- What to Learn:
- ID Token (JWT): 사용자의 프로필 정보가 담긴 물리적 서명 조각
- Scopes (OpenID, Profile, Email): 가져오고 싶은 수치적 정보의 범위 설정
- UserInfo Endpoint: 추가적인 신원 정보를 묻는 수리적 창구
- How to Learn:
- 받아온 ID Token의 내부 페이로드를 열어보고,
iss(발급자)와aud(대상) 필드가 내 하드웨어 정보와 맞는지 수리 대조 실습 - 'Implicit Flow'가 왜 보안 수치상 위험하여 현대 표준에서 물리적으로 지양되는지 연구
- 받아온 ID Token의 내부 페이로드를 열어보고,
- Implement: ID Token의 서명을 발급자의 공개키로 실시간 수리 검증하는
IdentityVerifier
Practical
Core: 기업용 SAML과 연합 인증 (Federation Mechanics)
- Why to Learn: 대기업 직원이 수백 개의 서로 다른 회사 하드웨어 툴을 비번 하나로 쓰게(SSO) 하기 위해서입니다.
- What to Learn:
- SAML Assertion: 사용자 정보가 담긴 거대한 수리적 XML 뭉치
- SP-Initiated vs IdP-Initiated: 인증이 시작되는 물리적 위치에 따른 흐름 차이
- Metadata Exchange: 서버 간에 서로의 공개키와 정보를 미리 교환하는 수순
- How to Learn:
Okta나Azure AD를 IdP로 설정하고, 가상의 웹 앱(SP)과 SAML로 신뢰 관계를 맺는 물리 설정 실습- SAML 응답 패킷의 'InResponseTo' 수리 필드를 조작했을 때, 하드웨어가 리플레이() 공격으로 간주하고 차단하는지 관찰
- Implement: SAML 응답 XML에서 서명된 본문(Assertion)을 추출하는
SAML_Parser
Advanced
Core: 프로토콜 보안 강화와 PKCE (High-end Protection)
- Why to Learn: 모바일 앱이나 자바스크립트 기반 웹처럼 비밀(Secret)을 숨길 수 없는 물리 환경에서 보안을 유지하기 위함입니다.
- What to Learn:
- PKCE (Proof Key for Code Exchange): 일회용 수리 비밀값()을 이용한 하이재킹 방어
- Token Introspection: 토큰이 아직 유효한지 실시간으로 하드웨어와 수리 대조하는 법
- MTLS for Tokens: 토큰을 가진 기기의 인증서(mTLS)를 확인하여 "토큰 묶기(Binding)"를 수행하는 물리 기술
- How to Learn:
- 스마트폰 앱 로그인 과정에서 PKCE 해시값이 네트워크를 통해 어떻게 수리적으로 전달되는지 패킷 분석 실습
- '토큰 스코프'를 필요 이상으로 넓게 잡았을 때, 한 서비스가 뚫리면 다른 물리 자원까지 털리는 수치적 파급력 연구
- Implement: PKCE 챌린지 생성을 위한
SHA-256기반의CodeChallengeGenerator
7. Terminology
8. References
Primary
- [P3] CyBOK - Software Security Knowledge Area (Identity Management) — Definitive protocol theory.
- [P5] SFIA v9 - Software Engineering / Methods and tools (Information security) — Management requirements.
Secondary
- [OAuth 2 in Action] Justin Richer — The best practical protocol handbook.
- [RFC 6749: The OAuth 2.0 Authorization Framework] — The source of truth.
Industry
- [Okta: Identity Identity 101] — Practical industry education.
- [Microsoft Entra: OAuth 2.0 and OIDC protocols] — Cloud implementation guide.
9. Final Checklist
Primary
- 'OAuth 2.0'의 '부인 방지' 기능이 '디지털 서명'이 포함된 'SAML'보다 수리적으로 왜 약한지 설명 가능한가? (P3)
- '인가 코드( )'와 '액세스 토큰'을 물리적으로 분리하여 전달해야 하는 근본적인 이유를 기술할 수 있는 가? (P3)
Secondary
- 'OIDC'의 'Discovery Document'가 하드웨어 클라이언트의 설정을 어떻게 수리적으로 자동화해 주는지 소통 가능한가?
- SAML의 'Issuer' 값이 실제 하드웨어의 도메인 신뢰도와 어떻게 수치적으로 연결되는지 논증할 수 있는 가?
Industry
- 실무 환경에서 여러 하드웨어 플랫폼(Web, iOS, Android)에 걸쳐 '통합 로그아웃'을 수리적으로 구현하는 거버넌스 수순을 제안할 수 있는 가? (SFIA)
- PKCE를 적용하지 않았을 때 '커스텀 URL 스킴'을 이용한 토큰 가로채기 공격이 물리적으로 어떻게 성립하는지 분석할 수 있는 가?