Identity, Access & Trust

1. Overview

신원, 접근 및 신뢰(Identity, Access & Trust, IAT)는 낯선 자원 요청자가 "내가 누구인지(Authentication)"를 증명하고, 시스템이 "네가 이 방에 들어갈 자격이 있는지(Authorization)"를 판별하는 논리적/수학적 통제 시스템을 다룹니다.

과거에는 하나의 시스템에 아이디/비밀번호만 치면 끝이었으나, 현대의 분산 시스템(MSA, 클라우드)에서는 수십 개의 서비스가 서로 통신하며 인증을 거쳐야 합니다. 학습자는 세션(Session) 기반 인증의 한계를 극복하는 JWT 토큰의 물리적 구조를 해부하고, 역할 기반 통제(RBAC)로 수만 명의 권한을 통제하는 관리 역학을 배웁니다. 나아가 '구글 로그인'의 뼈대인 OAuth 2.0과 OIDC 표준을 익혀, 여러 회사의 서버가 서로 얼굴도 모른 채 디지털 신뢰(Trust)를 위임하고 검증하는 페더레이션(Federation)의 위대한 메커니즘을 섭렵합니다.

2. Scope & Boundaries

In-Scope

• 인증 (Authentication, AuthN): 다중 요소 인증(MFA), FIDO, 생체 인증, 비밀번호 없는(Passwordless) 인증 역학.
• 인가 (Authorization, AuthZ): 역할 기반 접근 제어(RBAC), 속성 기반 접근 제어(ABAC), 최소 권한의 원칙.
• 토큰과 프로토콜 (Tokens & Protocols): 세션 vs 토큰(JWT) 구조 비교, OAuth 2.0 권한 위임 플로우, OpenID Connect(OIDC).
• 디렉토리 통합 (Identity Federation): SSO(Single Sign-On), SAML, Active Directory, IAM(Identity and Access Management).

Out-of-Scope

• 네트워크 IP 기반 접근 제어: 방화벽이나 Security Group을 통한 L3/L4 통신 차단 $\rightarrow$ 10-02. Infrastructure & Platform Security 영역으로 위임.
• 암호화 알고리즘 자체의 수학적 난제: RSA, 타원 곡선 암호의 세부 수학 증명 $\rightarrow$ 10-01. Security Foundations & Cryptography 영역으로 위임.

Boundaries

• IAT vs. SFC (10-01): 암호학(10-01)은 "데이터를 어떻게 암호화할 것인가?"라는 수단(도구)을 다룬다면, IAT는 그 암호학(디지털 서명, 해시)이라는 도구를 레고 블록처럼 조립하여 "저 녀석이 정말 김철수가 맞는지 어떻게 수학적으로 확신할 것인가?"를 구현하는 인증 시스템의 논리 아키텍처입니다.

3. Counterexample

• JWT의 암호화 오해 (JWT Secrecy Fallacy): "JWT를 썼으니 내 데이터는 안전하게 암호화되었다!"라고 착각하며 토큰의 페이로드(Payload) 안에 주민등록번호나 비밀번호를 담는 끔찍한 행위. JWT의 기본 형태는 암호화(Encryption)가 아니라 Base64로 단순 '인코딩(Encoding)'된 것일 뿐이어서 누구나 디코딩해 볼 수 있습니다. JWT의 본질은 정보 숨기기가 아니라, 서버의 비밀키로 만들어진 '서명(Signature)'을 통해 그 내용이 **조작되지 않았음(무결성)**을 수학적으로 증명하는 데 있습니다.
• OAuth를 '인증' 수단으로만 아는 착각 (OAuth is Authentication Fallacy): OAuth 2.0을 사용자가 누구인지 확인하는 규약으로 잘못 알고 있는 상황. OAuth 2.0은 "내가 가진 네이버 블로그의 글쓰기 권한을, 내 앱(Client)에게 위임(Delegation)하겠다"는 인가(Authorization) 프레임워크입니다. 인증(누구인가) 문제를 해결하기 위해서는 OAuth 2.0의 뼈대 위에 ID Token 개념을 덧붙인 **OIDC(OpenID Connect)**를 명확히 분별하여 사용해야 합니다.

4. Prerequisites

• 보안 기초 (Basic): 해시(Hash), 대칭키와 비대칭키(특히 디지털 서명)의 작동 원리를 모르면 JWT 토큰이 어떻게 무결성을 보장하는지 이해할 수 없습니다. (10-01. SFC)
• 웹 프로토콜 (Basic): HTTP의 무상태성(Stateless), 쿠키(Cookie)와 Authorization 헤더의 차이를 알아야 세션과 토큰의 아키텍처를 비교할 수 있습니다. (08-04. WAP)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 인증(Authentication)과 MFA 물리 (AuthN & MFA)

• Why to Learn: 인터넷 상의 누군가가 "나 관리자요"라고 주장할 때, 그 주장이 거짓말일 확률을 0에 가깝게 수렴시키기 위해서입니다.
• What to Learn:
  • Concepts: 인증(Authentication), 식별(Identification).
  • Skills: 다중 요소 인증(MFA: Multi-Factor Authentication)의 3요소 (지식, 소유, 존재), FIDO(Fast IDentity Online).
  • Tools: Google Authenticator (TOTP), WebAuthn.
  • Trade-offs: 비밀번호에 OTP와 지문 인식까지 강제하여 해커가 절대 못 뚫는 철벽 보안을 구축하는 것 vs 사용자가 로그인할 때마다 짜증이 나서 서비스를 이탈해버리는 극악의 UX 간의 줄다리기.
• How to Learn:
  • 1단계: 해커가 내 비밀번호를 알아냈더라도(지식 요소 털림), 내 주머니 속에 있는 스마트폰 앱(소유 요소)에서 30초마다 바뀌는 6자리 숫자(TOTP)를 입력해야만 접속이 허락되는 물리적/시간적 2차 방어선(2FA)의 원리를 해부합니다.
  • 2단계: 인증 정보를 훔쳐 가는 피싱 사이트를 무력화하기 위해, 브라우저가 사용자 기기의 지문 센서(존재 요소)와 공개키 암호를 엮어 인증하는 FIDO/WebAuthn의 최신 흐름을 스케치합니다.
• Implement: 파이썬이나 노드(Node.js)로 TOTP(Time-based One-Time Password) 생성 알고리즘 로직을 구현하고, QR 코드를 통해 Google Authenticator 앱과 연동하는 2FA 로그인 데모 구현.

Recommended

Core Topic 02: 인가(Authorization)와 접근 제어 모델 (AuthZ & RBAC)

• Why to Learn: 수천 명의 직원이 있는 회사에서 한 명 한 명에게 "어느 파일에 접근 가능한지"를 체크하는 불가능한 노동을 끝내고, 체계적 그룹으로 통제하기 위함입니다.
• What to Learn:
  • Concepts: 인가(Authorization), 최소 권한의 원칙(Principle of Least Privilege).
  • Skills: 임의적 접근 제어(DAC) vs 강제적 접근 제어(MAC), 역할 기반 접근 제어(RBAC), 속성 기반 접근 제어(ABAC).
  • Tools: AWS IAM, Spring Security / Casbin.
  • Trade-offs: 직원의 직급(Manager, Staff)으로만 권한을 자르는 RBAC의 단순하고 빠른 구현성 vs "오전 9시부터 6시까지만, 사내 IP에서만 접속 가능"과 같이 정밀한 제어가 필요할 때 도입하는 ABAC의 거대한 연산 복잡도.
• How to Learn:
  • 1단계: 리눅스 파일 시스템처럼 파일 주인이 권한을 남에게 맘대로 줄 수 있는 DAC의 한계와, 시스템(군대/정부)이 기밀 등급(Top Secret)에 따라 강제로 접근을 막아버리는 MAC의 엄격한 차이를 대비합니다.
  • 2단계: '회계팀장'이라는 역할(Role)을 만들고, 그 역할에 '급여 조회 권한'과 '송금 권한'을 연결합니다. 홍길동이 회계팀장이 되면 자동으로 2개의 권한이 따라오고, 다른 부서로 가면 즉각 권한이 떨어져 나가는 **RBAC(역할 기반 접근 제어)**의 관계형 물리(Entity Mapping)를 DB 테이블로 설계해 봅니다.
• Implement: Users, Roles, Permissions, User_Roles, Role_Permissions라는 5개의 DB 테이블을 설계하고 조인(Join)하여, 로그인한 사용자의 역할을 검증하는 백엔드 미들웨어(Middleware) 코드 작성.

Practical

Core Topic 03: 세션과 토큰(JWT) 아키텍처 (Session vs. Token)

• Why to Learn: 접속자가 10명일 땐 세션으로 버티다가 접속자가 10만 명으로 늘어나면 서버 메모리가 터져버리는 스케일 아웃(Scale-out)의 한계를 구조적으로 타파하기 위해서입니다.
• What to Learn:
  • Concepts: 상태 유지(Stateful: Session) vs 무상태(Stateless: JWT).
  • Skills: JWT(JSON Web Token)의 구조 (Header, Payload, Signature), Refresh Token 탈취 대응 역학, HMAC(대칭키 서명) vs RSA(비대칭키 서명).
  • Tools: jwt.io, Redis (세션 스토어).
  • Trade-offs: 토큰 자체가 사용자를 증명하므로 서버가 DB를 켤 필요 없이 즉시 통과시키는 무상태성(Stateless)의 극강 효율 vs 토큰이 해커에게 탈취당했을 때 만료 시간이 다 될 때까지 서버가 그것을 강제로 정지시킬 수 없는 치명적인 제어력 상실(Revocation Problem).
• How to Learn:
  • 1단계: 세션 기반 인증에서 1번 서버에 로그인한 유저가 로드밸런서에 의해 2번 서버로 갔을 때 "누구세요?"라며 로그아웃되는 문제를 인지하고, 이를 해결하기 위해 Redis(세션 클러스터링)를 도입하는 끈적한 세션(Sticky Session)의 고통을 이해합니다.
  • 2단계: "내 이름은 철수고, 권한은 Admin이야. 그리고 이 정보가 위조되지 않았다는 걸 서버 비밀키 서명(Signature)이 증명해"라는 데이터 덩어리인 JWT를 만들어, 100대의 서버 어디를 가든 DB 조회 없이 즉각 인증되는 마법을 실습합니다.
• Implement: Access Token(수명 15분)과 Refresh Token(수명 7일)의 이원화 구조를 구현하고, 프론트엔드에서 Access Token 만료 시 Refresh Token으로 새 토큰을 재발급받는 보안 API 플로우 구축.

Advanced

Core Topic 04: 연합 인증과 OAuth 2.0 / OIDC (Identity Federation & SSO)

• Why to Learn: 스타트업을 만들 때 회원가입 폼을 만드는 대신 "구글 계정으로 로그인" 버튼 하나를 달아 유저 전환율을 10배 끌어올리기 위함입니다.
• What to Learn:
  • Concepts: 단일 로그온(SSO: Single Sign-On), 아이덴티티 페더레이션(Identity Federation).
  • Skills: OAuth 2.0의 역할(Resource Owner, Client, Authorization Server, Resource Server)과 Grant Type(Authorization Code Flow), OIDC(OpenID Connect)의 ID Token 물리.
  • Tools: Keycloak, Auth0, Google Identity Platform.
  • Trade-offs: 로그인 시스템 개발을 통째로 글로벌 기업(구글, 애플)에게 아웃소싱하여 얻는 압도적 보안과 편의성 vs 우리 고객의 귀중한 접속 데이터를 대기업에 고스란히 바치는 플랫폼 종속(Vendor Lock-in).
• How to Learn:
  • 1단계: 사용자가 '내 앱(Client)'에서 '구글 로그인' 버튼을 누르면, 구글(Authorization Server)로 날아가 로그인을 마치고 인증 코드(Code)를 받아 내 서버로 돌아오고, 내 서버가 뒤쪽에서 그 코드를 진짜 구글 서버와 통신해 액세스 토큰으로 교환하는 웅장한 핑퐁 릴레이(Authorization Code Flow)를 시퀀스 다이어그램으로 추적합니다.
  • 2단계: OAuth 2.0이 반환하는 'Access Token'은 구글 캘린더나 드라이브를 수정할 '권한(인가)'일 뿐, 사용자 정보 그 자체가 아님을 인지합니다. 이 약점을 극복하기 위해 나온 OIDC 표준이 어떻게 JWT 형태의 'ID Token'을 던져주어 사용자 인증(Authentication)을 명확히 하는지 그 진화 과정을 해부합니다.
• Implement: OAuth 2.0 흐름(Authorization Code Flow)을 직접 코드로 구현하여, 외부 서비스(예: GitHub, Google)로부터 Access Token과 ID Token을 발급받아 사용자 정보를 파싱(Parsing)해오는 소셜 로그인 통합 시스템 작성.

7. Terminology

8. References

Primary References

• [P3] CyBOK - Authentication, Authorization & Accountability (AAA) — Identity standards.
• [P1] CS2023 - SEC/Identity and Trust Management — Foundational concepts.

Secondary References

• [O'Reilly - OAuth 2 in Action] Justin Richer — Detailed protocol guide.
• [Identity in the Age of Cloud] Various authors — Modern IAM strategies.

Industry References

• [OAuth 2.0 Specification (RFC 6749)] — Official IETF standard.
• [Microsoft Entra ID (Azure AD) Documentation] — Real-world enterprise IAM implementation.

9. Final Checklist

Primary Checklist

• 인증(Authentication)이 성공했더라도 적절한 인가(Authorization) 절차가 누락되었을 때 발생할 수 있는 '수평적/수직적 권한 상승' 사고를 물리적으로 방지할 수 있는가? (P3)
• 비밀번호 저장 시 복호화가 불가능한 '일방향 해시'와 '솔트'를 결합해야 하는 보안적 필연성을 기술할 수 있는능가? (P1)

Secondary Checklist

• JWT의 페이로드(Payload)에는 민감한 정보를 담아서는 안 되는 이유를 토큰의 물리적 구조(Base64 인코딩)와 연결하여 설명 가능한가?
• OAuth 2.0의 'State' 파라미터가 CSRF 공격을 물리적으로 어떻게 차단하는지 그 방어 논리를 이해하고 있는가?

Industry Checklist

• 실무 서비스 설계 시, 사용자 경험(UX)과 보안 강도(SFA vs MFA) 사이의 균형점을 데이터 기반으로 제안 가능한가? (SFIA)
• 클라우드 IAM 정책에서 와일드카드(*) 사용의 위험성을 인지하고, 특정 리소스에 한정한 정밀한 권한 제어를 수행할 수 있는 있는가?