Authentication, Session과 JWT

Overview

Authentication은 누구인지 확인하고 Authorization은 무엇을 할 수 있는지 판단한다. SAML은 조직 간 Web SSO Federation에, JWT는 서명된 Claim을 API 사이에서 전달하는 형식에 주로 쓰인다. 둘은 경쟁 제품이 아니라 다른 경계에서 함께 쓸 수 있다.

Server Session은 인증 결과를 서버 저장소에 보관하고 Browser에는 Session ID만 주는 방식이다. Stateless JWT는 인증 결과와 Claim을 서명된 Token에 담아 서버가 매 요청마다 Session Store를 조회하지 않아도 검증할 수 있게 한다. 선택 기준은 “즉시 통제”와 “분산 확장” 중 어디에 무게를 둘지다.

한 문장 설명: Session은 출입 명부를 프런트 데스크가 보관하고 손님에게 번호표를 주는 방식이고, JWT는 만료 시간이 적힌 서명된 출입증을 손님이 들고 다니는 방식이다.

sequenceDiagram; participant U as User; participant SP as Service; participant IDP as IdP; participant API as API; U->>SP: Login; SP->>IDP: SAML Authn Request; IDP-->>SP: 서명된 Assertion; SP-->>U: Session 또는 짧은 Token; U->>API: Bearer JWT; API->>API: 서명·iss·aud·exp 검증

Session 기반 인증

Session 방식에서는 Login 성공 후 서버가 sessionId -> userId, 권한, 만료, CSRF 상태 같은 값을 저장한다. Client는 Cookie로 Session ID를 보내고 서버는 저장소에서 인증 상태를 찾는다. 중요한 점은 Cookie 자체가 사용자의 모든 정보를 담는 것이 아니라 서버 쪽 상태를 가리키는 Handle이라는 점이다.

장점은 통제가 쉽다는 것이다. Logout, 관리자 강제 차단, 권한 변경을 서버 저장소에서 바로 반영할 수 있다. 단점은 API Server가 Session Store에 의존하므로 저장소 장애와 지연, 확장 구조를 설계해야 한다는 것이다.

Sticky Session

Sticky Session은 Load Balancer가 같은 사용자의 요청을 같은 Application Server로 보내는 방식이다. 서버 메모리에 Session을 들고 있을 때 간단히 확장할 수 있지만, 특정 Instance에 사용자가 몰리거나 Instance가 죽으면 Session이 사라질 수 있다.

Production에서는 Sticky Session만 믿기보다 Redis 같은 외부 Session Store, Session Replication, 짧은 장애 허용 정책을 검토한다. Sticky는 편의 장치이지 인증 상태의 유일한 저장 전략으로 두기에는 장애와 배포에 약하다.

Stateless와 JWT

Stateless API는 요청 하나를 처리하는 데 필요한 인증 정보를 요청 자체에서 검증하고, 서버 Instance의 메모리 상태에 의존하지 않는 구조다. JWT는 이 구조에 잘 맞는다. API는 Signature, Issuer, Audience, Expiration을 검증하고 Claim으로 사용자와 권한 범위를 판단한다.

하지만 “JWT를 쓰면 완전 무상태”는 아니다. Refresh Token Rotation, Logout, Revocation, 위험 사용자 차단, 권한 즉시 반영에는 서버 측 상태가 필요할 수 있다. 실무에서는 Access Token은 짧게 무상태 검증하고, Refresh Session과 폐기 목록은 상태로 관리하는 혼합 구조가 많다.

JWT 검증

Base64 Decode는 검증이 아니다. Signature, 허용 Algorithm, Issuer, Audience, Expiry와 Not-Before를 확인한다. Access Token은 짧게 유지하고 Refresh Token Rotation·폐기 정책을 별도로 둔다. 민감한 정보는 암호화되지 않은 JWT Payload에 넣지 않는다.

SAML 검증

Assertion Signature, Issuer, Audience, Recipient, 시간 조건, Replay 방지를 검증한다. Service Provider와 Identity Provider의 Metadata·Certificate Rotation 절차가 필요하다.

Trade-off와 실패 모드

Stateless Token은 Service 확장이 쉽지만 즉시 폐기와 권한 변경 반영이 어렵다. Server Session은 중앙 제어가 쉽지만 저장소 가용성과 확장 설계가 필요하다. 인증 성공을 인가 성공으로 혼동하거나 긴 Token 수명, Log Token 노출, Clock Skew 무시가 자주 문제 된다.

다른 사람에게 설명한다면

30초: “Session은 서버가 인증 상태를 저장하고 Client는 Session ID만 들고 다니는 방식입니다. JWT는 서명된 Claim을 Client가 들고 다니고 서버가 매 요청 검증하는 방식입니다. Session은 즉시 통제에 강하고, JWT는 분산 API 확장에 유리하지만 폐기와 권한 변경 반영이 어렵습니다.”

2분: Login 후 Session ID Cookie와 Server Store 조회 흐름, Load Balancer의 Sticky Session, JWT의 Signature·iss·aud·exp 검증, Access/Refresh Hybrid 구조를 비교한다. 마지막에는 “상태가 있느냐 없느냐가 목적이 아니라 보안 통제와 확장 비용의 균형을 정하는 문제”라고 정리한다.

Interview Questions

1. Authentication과 Authorization의 차이는?
2. JWT Decode와 Verify는 어떻게 다른가?
3. SAML과 JWT를 함께 사용하는 흐름은?
4. Stateless Access Token을 즉시 폐기하기 어려운 이유는?
5. Session 기반 인증과 Stateless JWT 인증의 Trade-off는?
6. Sticky Session이 필요한 상황과 한계는?

Related Topics

JWT 구조와 서명 검증, Access·Refresh Token 수명주기, TLS와 인증서로 이어진다.