303. 인증 (Authentication) 및 인가 (Authorization) 패턴

핵심 인사이트 (3줄 요약)

1. 본질: 인증(Authentication, "너는 누구인가?")과 인가(Authorization, "네가 이것을 할 권한이 있는가?")는 시스템의 가장 앞단에서 불법적인 접근을 차단하는 보안 아키텍처의 절대적인 두 기둥이다.
2. 가치: 모놀리식 시스템에서는 세션(Session) 하나로 둘 다 처리했지만, 마이크로서비스(MSA)와 모바일/클라우드 환경에서는 이를 분산 처리하기 위한 JWT(JSON Web Token), OAuth 2.0, RBAC/ABAC 같은 고도화된 아키텍처 패턴이 비즈니스의 스케일링을 결정짓는다.
3. 융합: 이 패턴들은 API 게이트웨이(API Gateway)와 결합하여 전사적인 보안 장벽(Token-based Authentication)을 세우고, 제로 트러스트(Zero Trust) 아키텍처를 구현하는 핵심 엔진으로 작동한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념:

  • 인증 (Authentication, AuthN): 시스템에 접근하려는 주체(User, System)가 자신이 주장하는 그 사람이 맞는지(ID/PW, 생체정보 등으로) 확인하는 절차.
  • 인가 (Authorization, AuthZ): 인증된 주체가 특정 자원(게시판, 관리자 페이지)에 접근하거나 행동을 할 수 있는 '권한(Permission)'이 있는지 검증하는 절차.

• 필요성: 놀이공원에 비유해 보자. 매표소에서 신분증과 지문을 확인해 놀이공원 입장을 허락하는 것이 인증이다. 하지만 놀이공원에 들어왔다고 해서 누구나 롤러코스터 조종실에 들어갈 수는 없다. 일반 손님은 놀이기구 탑승만 가능하고, 직원은 조종실에 들어갈 수 있게 명찰 색깔로 통제하는 것이 인가다. 이 두 가지가 시스템적으로 명확히 분리되지 않으면 일반 손님이 롤러코스터를 조종하는 대참사가 터진다.

• 💡 비유: **인증(AuthN)**은 여권을 보여주고 비행기 표를 받는 것이고, **인가(AuthZ)**는 비행기 안에서 이코노미석에 앉을지 일등석에 앉을지 표의 등급을 확인받는 것입니다. 일등석 표를 가졌어도(인가) 여권이 가짜면(인증) 애초에 공항에 못 들어가고, 여권이 진짜라도 일등석 표가 없으면 일등석에 못 앉습니다.

• 등장 배경 및 발전 과정:

  1. 상태 유지(Stateful) 세션 인증: 과거 웹에서는 서버가 메모리나 DB에 로그인한 사람의 명부(Session ID)를 기록해 두고 매번 대조했다. 동시접속자가 1천만 명이 되자 서버 메모리가 터졌다.
  2. 무상태(Stateless) 토큰 인증: 서버가 기억하는 대신, 위조 불가능한 도장이 찍힌 출입증(Token, JWT)을 사용자에게 줘버렸다. 사용자가 올 때마다 서버는 이 도장만 검사하면 되므로 서버 대수를 무한대로 늘릴 수 있게 되었다(MSA 최적화).
  3. 권한 위임 (OAuth 2.0): 구글, 카카오 같은 거대 플랫폼이 생기며, 내 앱이 구글의 아이디와 패스워드를 묻지 않고도 구글의 '권한'만 빌려오는 OAuth 패턴이 인터넷의 표준으로 자리 잡았다.

• 📢 섹션 요약 비유: 옛날엔 식당 주인이 단골손님 100명의 얼굴과 외상 장부를 다 외웠지만(세션), 손님이 1만 명으로 늘어나자 도저히 외울 수 없어 손님들에게 지워지지 않는 도장이 찍힌 쿠폰(JWT 토큰)을 나눠주고 쿠폰만 보고 들여보내는 방식으로 바뀐 것입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 인증(Authentication) 아키텍처 패턴

현대 분산 시스템에서 인증을 처리하는 가장 강력한 3가지 패턴이다.

A. 서버 측 세션 기반 인증 (Server-side Session)

• 원리: 클라이언트가 ID/PW를 보내면 서버가 인증 후 Session ID를 만들어 응답 쿠키(Cookie)에 내려준다. 서버는 이 ID를 메모리나 세션 클러스터(Redis)에 저장해 둔다.
• 장점: 사용자를 강제로 로그아웃(세션 만료) 시키거나 기기 제어를 하기 가장 완벽하고 보안성이 높다.
• 단점: 사용자가 스케일 아웃(Scale-out)된 여러 대의 서버를 오갈 때, 세션 정보(Redis)를 계속 뒤져야 하므로 오버헤드가 발생한다.

B. 토큰 기반 인증 (Token-based Authentication / JWT)

• 원리: 클라이언트가 인증에 성공하면, 서버는 사용자의 정보와 유효기간을 암호학적으로 서명(HMAC, RSA)한 **JWT (JSON Web Token)**를 발급한다.
• 장점: 서버는 토큰을 저장하지 않는다(Stateless). CPU 연산만으로 서명의 유효성을 0.001초 만에 검증할 수 있어 MSA의 수백 개 서버 스케일 아웃에 가장 완벽한 패턴이다.
• 단점: 한 번 발급된 JWT 토큰은 유효기간이 끝날 때까지 서버가 강제로 취소(로그아웃)시킬 수 없다는 치명적인 약점(Token Revocation 문제)이 있다.

C. 단일 로그인 (SSO, Single Sign-On)

• 원리: 구글, 사내망 등 여러 개의 시스템이 있을 때, 사용자가 통합 인증 서버(IdP, Identity Provider)에서 딱 1번만 로그인하면 나머지 모든 패밀리 사이트는 인증을 패스하는 패턴. SAML이나 OAuth/OIDC(OpenID Connect) 프로토콜을 사용한다.

2. 인가(Authorization) 아키텍처 패턴

누가 접속했는지(인증) 알았다면, 이 사람이 어떤 API를 찌를 수 있는지(인가)를 판단하는 2대 아키텍처 뼈대다.

A. RBAC (Role-Based Access Control, 역할 기반 접근 제어)

• 개념: 사용자의 개별 신분이 아니라, **사용자가 가진 '역할(Role)'**에 권한을 매핑하는 가장 널리 쓰이는 표준 패턴.
• 구조: User ─(N:M)─▶ Role ─(N:M)─▶ Permission. (예: 홍길동은 '과장' Role을 가짐. '과장' Role은 '결재 승인' Permission을 가짐).
• 장점: 직원이 1만 명이어도 역할(사원, 대리, 과장)만 관리하면 되므로 관리가 매우 직관적이고 편하다.
• 단점: "서울 지점의 마케팅 부서 대리이면서 평일에만 접근 가능" 같은 세밀한 조건을 짤 수 없어 '역할 폭발(Role Explosion)' 현상이 생긴다.

B. ABAC (Attribute-Based Access Control, 속성 기반 접근 제어)

• 개념: 역할뿐만 아니라 사용자, 자원, 환경의 **모든 '속성(Attribute)'을 조합한 동적인 규칙(Rule)**으로 권한을 판단하는 차세대 권한 패턴.

• 구조: If (User.Dept == "HR" AND Resource.Type == "Salary" AND Time < 18:00) Then Allow.

• 장점: 1개의 완벽하고 세밀한 룰로 모든 예외 상황을 커버할 수 있어 제로 트러스트(Zero Trust) 아키텍처의 근간이 된다. 클라우드 인프라(AWS IAM Policy)가 ABAC 방식이다.

• 단점: 룰 엔진을 구축하고 매번 룰을 파싱(해석자 패턴)해야 하므로 성능(오버헤드)이 떨어지고 설계가 극도로 어렵다.

• 📢 섹션 요약 비유: RBAC가 "임산부 배지(Role)를 단 사람만 핑크색 좌석에 앉으세요"라는 쉬운 직관적 룰이라면, ABAC는 "체온이 37도 이상이거나 짐이 10kg 이상이면서 버스가 붐비는 시간일 때만 이 자리에 앉으세요"라는 아주 깐깐하고 정확한 컴퓨터식 판단 룰입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 인증/인가의 궁극적 난제: 토큰 탈취와 Refresh Token

MSA 환경에서 가장 많이 쓰는 JWT(토큰) 방식의 최대 약점은 "해커가 토큰을 훔쳐 가면 만료될 때까지 속수무책"이라는 점이다. 이를 해결하기 위해 아키텍트는 이중 토큰(Two-Token) 아키텍처를 설계한다.

과목 융합 관점

• 네트워크 / 보안: OAuth 2.0 프레임워크는 인증이 아닌 '권한 위임(인가)' 프로토콜이다. 여기에 신원 확인(인증) 레이어를 덧붙인 것이 **OIDC (OpenID Connect)**다. 이 두 프로토콜이 맞물려 전 세계 인터넷의 소셜 로그인(SSO) 아키텍처를 지배하고 있다.

• 소프트웨어 공학 (SE): API 게이트웨이(API Gateway)가 가장 중요하게 활약하는 곳이다. 클라이언트가 수백 개의 MSA 서버를 찌를 때마다 각 서버가 인증/인가를 하면 중복 코드가 엄청나다. 앞단의 API Gateway가 JWT를 뜯어서 유효성을 1차 검사(인증)하고, 찐 정보만 헤더에 달아 뒷단으로 넘겨주어(Cross-Cutting Concern 분리) 아키텍처를 깔끔하게 만든다.

• 📢 섹션 요약 비유: 수명이 15분짜리 1회용 방문증(Access Token)만 손에 들려주고, 기간이 1달짜리 진짜 신분증(Refresh Token)은 꺼낼 수 없는 비밀 주머니(HttpOnly 쿠키)에 꿰매버리는 완벽한 방어 설계입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 토큰 강제 만료(Revocation) 불가로 인한 대참사: 해커가 쇼핑몰 관리자 PC에 악성코드를 심어 관리자의 JWT(Access Token, 수명 24시간)를 훔쳤다. 해커가 이 토큰으로 회원들의 등급을 마구 깎아내리자, 쇼핑몰 대표는 다급히 "저 해커를 즉시 강제 로그아웃 시키라!"고 소리쳤다. 그러나 개발자는 "서버에 세션 DB가 없고 JWT는 자기 혼자 24시간 살아 움직이므로, 24시간이 지날 때까지 해커를 막을 방법이 없습니다"라고 절망적인 대답을 내놓았다.

   • 아키텍트의 해결책: MSA 환경에서 'JWT 토큰 블랙리스트(Blacklist)' 아키텍처를 설계하지 않은 직무 유기다. JWT는 Stateless(서버가 모름)가 장점이지만, 비상 상황을 위해 서버는 Redis 같은 초고속 인메모리 DB에 '로그아웃되거나 해킹당한 토큰 목록(블랙리스트)'을 올려두어야 한다. API Gateway는 토큰의 암호학적 서명이 맞더라도, 1초 만에 Redis를 찔러 이 토큰이 블랙리스트에 있는지 2차 검증하는 하이브리드(Stateful + Stateless) 방어막을 쳐야만 한다.

2. 시나리오 — IDOR(Insecure Direct Object Reference)에 의한 타인 정보 탈취: 사용자가 자신의 개인정보를 보는 API가 GET /users/50 이다. 백엔드 개발자는 스프링 시큐리티(Spring Security)로 사용자가 "로그인했는지(인증)"와 "User 권한이 있는지(인가)"를 완벽하게 필터로 짰다. 그런데 한 악의적 유저가 로그인 후 GET /users/51 이라고 숫자만 바꿔 호출하자, 남의 개인정보가 그대로 다 털렸다.

   • 아키텍트의 해결책: **데이터 객체 수준의 인가(Data-Level Authorization)**를 빼먹은 끔찍한 안티패턴이다. RBAC 필터로 "User 권한이 있다"는 것은 통과시켰지만, 도메인 로직 안에서 **"현재 로그인한 토큰의 주인이, 조회하려는 51번 유저와 동일인인가?"**를 검사하는 비즈니스 방어 코드(ABAC의 일종)를 한 줄도 짜지 않은 것이다. 아키텍트는 메서드 보안(@PreAuthorize("#id == authentication.principal.id"))을 강제하여 이 취약점을 시스템적으로 회피해야 한다.

도입 체크리스트

• 기술적: 사내 시스템이 커지면서 여러 개의 서버가 돌아갈 때, 중앙화된 **IdP (Identity Provider, 예: Keycloak, Okta)**를 도입했는가? 각 팀이 각자 유저 테이블과 패스워드 로직을 짜게 놔두면 보안은 100% 박살 나고 관리 포인트만 기하급수적으로 늘어난다. (SSO의 필수 도입)
• 보안적: 비밀번호를 DB에 평문(Plain text)으로 저장하지 않는 건 기본 중의 기본이다. 단방향 해시(SHA-256)를 쓸 때, 반드시 계정마다 무작위 문자열인 **솔트(Salt)**를 추가하여 레인보우 테이블(Rainbow Table) 해킹을 무력화했는가? 더 나아가 Bcrypt, Argon2 등 계산에 고의로 시간을 끄는(Key Stretching) 최신 알고리즘을 썼는가?

안티패턴

• JWT 암호화의 환상 (JWT는 암호화가 아니다): JWT를 Base64로 인코딩한 것일 뿐, 그 안의 페이로드(Payload)는 누구나 디코딩해서 훤히 들여다볼 수 있다. 초보 개발자가 JWT 안에 고객의 '주민등록번호'나 '비밀번호'를 넣어서 프론트로 던지는 행위는 회사 문을 닫겠다는 최악의 범죄다. JWT에는 오직 식별용 아이디(user_id)나 만료 시간만 담아야 한다.

• 📢 섹션 요약 비유: JWT 토큰은 투명한 비닐봉지 위에 '국가가 찍은 도장'이 있는 출입증입니다. 도장(서명)이 진짜인지 가짜인지는 속일 수 없지만, 비닐봉지 속 내용물(주민번호)은 누구나 밖에서 다 쳐다볼 수 있습니다. 중요한 물건은 절대 비닐봉지에 넣으면 안 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 비밀번호 없는 시대 (Passwordless Authentication): 피싱(Phishing)과 해킹의 80%는 허술한 비밀번호에서 온다. 이제는 Apple의 FaceID, Windows Hello, 구글 패스키(Passkey) 등 생체 인식 장치가 만든 FIDO2 표준을 통해, 서버에 비밀번호를 아예 저장하지 않고 오직 스마트폰의 개인키로 서명(Signature)만 주고받는 완벽한 탈비밀번호 시대로 인터넷이 전면 개편되고 있다.
• 제로 트러스트와 연속 인증 (Continuous Authentication): 한 번 로그인했다고 24시간 내내 믿어주는 시대는 끝났다. 사용자가 갑자기 평소 안 가던 심야 시간에 접속하거나 마우스 움직임이 봇(Bot) 같으면, 서버가 실시간으로 신뢰도 점수(Trust Score)를 깎고 재차 지문 인증(MFA)을 요구하는 능동적이고 편집증적인 ABAC 모델로 진화 중이다.

참고 표준

• OAuth 2.0 (RFC 6749) & OIDC (OpenID Connect): 웹과 모바일 앱의 3자 간 권한 위임 및 신원 인증을 위한 절대적인 세계 표준 프레임워크.
• JWT (RFC 7519): JSON 형식의 클레임 정보를 안전하게 전달하기 위한 토큰 표준 규격.

인증과 인가 패턴은 디지털 세계의 **"법과 질서(Law and Order)"**를 세우는 설계다. 기술사는 문을 꼭꼭 걸어 잠그기만 하는 폐쇄적인 설계에서 벗어나, 1억 명의 선량한 사용자는 문을 열지 않고도 하이패스(JWT/SSO)로 통과하게 만들면서도, 단 1명의 악당은 철옹성 같은 권한 분리(ABAC/RBAC)의 감옥에 가두어 시스템을 손끝 하나 건드리지 못하게 만드는 완벽한 출입국 관리소(Architecture)를 지어 올려야 한다.

• 📢 섹션 요약 비유: 옛날 성벽 방어가 매번 신분증을 꺼내 대조하며 사람들을 몇 시간씩 줄 서게 만드는 것이었다면, 현대의 인증/인가 아키텍처는 보이지 않는 레이저 스캐너가 사람들의 얼굴과 걸음걸이를 0.1초 만에 분석하여 선량한 시민 앞의 문을 마법처럼 스르륵 열어주는 최첨단 공항 검색대와 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 영화관에 들어갈 때, 표 받는 아저씨가 "티켓 보여주세요~" 하고 확인하는 것이 바로 **'인증(네가 손님이 맞는지)'**이에요.
2. 영화관에 들어왔다고 끝이 아니에요. 내 티켓에 적힌 자리가 'VVIP석'인지 '일반석'인지 확인하고 딴 자리에 못 앉게 막는 것이 **'인가(어떤 권한을 가졌는지)'**랍니다.
3. 이렇게 나쁜 사람이 몰래 들어오는 걸 1차로 막고, 들어왔어도 엉뚱한 짓을 못하게 2차로 또 막는 튼튼한 자물쇠 시스템을 **'인증과 인가 패턴'**이라고 부른답니다!