콘텐츠로 바로가기

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

  1. The Messenger of Trust: 내가 직접 신분증을 확인하지 않고, 믿을 만한 형님(IdP)의 보증을 받는 물리 논리를 이해합니다.
  2. Standard Languages: OAuth2와 SAML이라는 전 세계 공용 보안 언어의 수리적 문법을 익힙니다.
  3. The Layer of Identity: 단순히 문만 열어주는 것을 넘어, "이 사람의 이름은 무엇인가"라는 정보(OIDC)를 물리적으로 나릅니다.
  4. 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

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'가 왜 보안 수치상 위험하여 현대 표준에서 물리적으로 지양되는지 연구
  • 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:
    • OktaAzure AD를 IdP로 설정하고, 가상의 웹 앱(SP)과 SAML로 신뢰 관계를 맺는 물리 설정 실습
    • SAML 응답 패킷의 'InResponseTo' 수리 필드를 조작했을 때, 하드웨어가 리플레이(ReplayReplay) 공격으로 간주하고 차단하는지 관찰
  • 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): 일회용 수리 비밀값(VerifierVerifier)을 이용한 하이재킹 방어
    • Token Introspection: 토큰이 아직 유효한지 실시간으로 하드웨어와 수리 대조하는 법
    • MTLS for Tokens: 토큰을 가진 기기의 인증서(mTLS)를 확인하여 "토큰 묶기(Binding)"를 수행하는 물리 기술
  • How to Learn:
    • 스마트폰 앱 로그인 과정에서 PKCE 해시값이 네트워크를 통해 어떻게 수리적으로 전달되는지 패킷 분석 실습
    • '토큰 스코프'를 필요 이상으로 넓게 잡았을 때, 한 서비스가 뚫리면 다른 물리 자원까지 털리는 수치적 파급력 연구
  • Implement: PKCE 챌린지 생성을 위한 SHA-256 기반의 CodeChallengeGenerator

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
OAuth 2.0 데이터 소유자 대신 서드파티 앱이 하드웨어 자원에 접근할 수 있게 하는 인가 프레임워크입니다. 기본 권한 위임 Grant / Scope OIDC 인증(AuthN) 규격이 아님 Industry core
OIDC OAuth 2.0 위에서 동작하며, 사용자의 신원을 수리적으로 확인하고 프로필 정보를 제공하는 프로토콜입니다. 추천 신원 확인 ID Token / JWT OAuth2 OAuth2의 확장이지만 '인증'용임 Industry core
SAML 서로 다른 보안 도메인 간에 신원 인식 및 인가 데이터를 XML로 주고받는 물리적 표준입니다. 실무 기업 통합 IdP / SP OIDC 웹보단 기업 내부 SSO에 강점 Industry core
PKCE 클라이언트 시크릿을 안전하게 보관할 수 없는 환경에서 OAuth2의 수리적 보안을 강화하는 기법입니다. 실무 앱 보안 Verifier / Challenge Flow 현대 모바일/SPA 필수 수순 Industry core

8. References

Primary

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)
  • '인가 코드(AuthorizationAuthorization CodeCode)'와 '액세스 토큰'을 물리적으로 분리하여 전달해야 하는 근본적인 이유를 기술할 수 있는 가? (P3)

Secondary

  • 'OIDC'의 'Discovery Document'가 하드웨어 클라이언트의 설정을 어떻게 수리적으로 자동화해 주는지 소통 가능한가?
  • SAML의 'Issuer' 값이 실제 하드웨어의 도메인 신뢰도와 어떻게 수치적으로 연결되는지 논증할 수 있는 가?

Industry

  • 실무 환경에서 여러 하드웨어 플랫폼(Web, iOS, Android)에 걸쳐 '통합 로그아웃'을 수리적으로 구현하는 거버넌스 수순을 제안할 수 있는 가? (SFIA)
  • PKCE를 적용하지 않았을 때 '커스텀 URL 스킴'을 이용한 토큰 가로채기 공격이 물리적으로 어떻게 성립하는지 분석할 수 있는 가?