인증(Authentication)과 인가(Authorization) 그리고 서비스 규모에 따른 인증인가 변천사

인증이란 무엇인가

인증은 사용자가 누구인지 확인하는 과정입니다.
로그인을 예로 들면, 사용자가 입력한 아이디와 비밀번호가 데이터베이스에 저장된 값과 일치하는지 확인하는 과정이 바로 인증입니다.

예를 들어 출입증을 받는 상황을 생각해보시면 이해가 쉽습니다. 출입증을 통해 해당 인물이 실제 구성원인지 입증하는 것이 곧 인증입니다.

 

인증 처리가 되지 않으면 서버는 클라이언트에게 401 에러를 응답할 수 있습니다. 

401 에러는 "권한 없음(Unauthorized)"을 의미하는 HTTP 상태 코드로, 사용자가 요청한 리소스에 접근하기 위한 유효한 인증 정보(로그인 정보 등)가 부족하기 때문에 발생합니다. 
이 에러를 해결하려면 로그인 정보를 다시 확인하고 올바르게 입력하거나, 브라우저 캐시를 삭제하거나, 사이트 관리자에게 문의하여 계정 접근을 요청해야 합니다.

 

• 401 Unauthorized
  • “현재 요청은 인증이 필요하다”는 뜻입니다.
  • 즉, 사용자가 누구인지 알 수 없는 상태입니다.
• 주요 상황
  • 로그인하지 않은 사용자가 보호된 API 호출 시도
  • 잘못된 토큰(JWT) 또는 만료된 토큰으로 요청
  • Authorization 헤더가 누락된 경우

 

 

인가란 무엇인가

인가(Authorization)는 인증된 사용자에게 특정 자원에 대한 접근 권한을 부여하거나 검증하는 과정입니다.
즉, “누구인지”가 확인된 뒤, “무엇을 할 수 있는가”를 판단하는 단계입니다.

예를 들어 같은 회사 출입증을 가진 두 사람이라도, 한 명은 14층까지만 갈 수 있고 다른 한 명은 12층 VIP 구역에도 갈 수 있다고 하면, 이 차이가 인가입니다.

 

권한이 허용 되지 않으면 서버는 클라이언트에게 403 에러를 응답할 수 있습니다. 

403 Forbidden 오류는 클라이언트(사용자)가 웹 서버에 요청을 보냈지만, 서버가 해당 요청에 대한 접근 권한이 없다고 판단하여 접근을 거부할 때 발생하는 HTTP 상태 코드입니다. 이 오류는 서버가 사용자를 인식했지만, 특정 리소스에 접근할 수 있는 권한이 없음을 의미합니다. 

 

• 403 Forbidden
  • “요청은 이해했지만, 인가되지 않은 사용자라서 거부한다”는 뜻입니다.
  • 즉, 누구인지는 알지만 권한이 없는 상태입니다.
• 주요 상황
  • 일반 사용자(USER)가 관리자 페이지(ADMIN)에 접근
  • 파일 다운로드 권한이 없는 계정이 해당 리소스를 요청
  • RBAC(Role Based Access Control)에서 권한 매칭 실패

 

 

401 vs 403 차이 정리

 

	401 Unauthorized	403 Forbidden
문제	인증 실패 (누군지 모름)	인가 실패 (누군지는 아는데 권한 없음)
원인	로그인 필요, 토큰 없음/만료/잘못됨	권한(Role, Scope) 부족
해결	재로그인, 토큰 갱신 필요	관리자 권한 요청, 권한 정책 수정 필요
예시	만료된 JWT 토큰 요청	USER 권한으로 ADMIN API 호출

---

 

웹 서비스에서의 적용

항상 인증 → 인가 순으로 진행됩니다. 인증이 선행되지 않으면 인가는 의미가 없습니다.
“이 사용자가 누구인지 모르는 상태에서 권한을 줄 수는 없기 때문”입니다.

 

• 인증: 로그인 (아이디/비밀번호, OAuth 소셜 로그인, 인증 서버 기반)
• 인가: 권한(Role)에 따른 접근 제어 (예: USER는 자신이 작성한 글만 수정 가능, ADMIN은 모든 글 삭제 가능)

 

서비스 성장에 따른 인증·인가의 변천사

 

기본 인증(Basic Auth)

단일 서버, 단순 API에서 “지금 당장 인증만 되면 된다”는 요구상황을 만족시키기 위해, 초기 프로젝트 인증인가로 사용했습니다. 브라우저/클라이언트가 Authorization: Basic <base64(id:pw)> 헤더를 보냅니다. 또는 폼 데이터에 계정 정보와 비밀번호를 보내기 도 하죠. 구현이 매우 단순합니다. 서버는 매 요청마다 헤더를 복호화하여 DB로 검증하면 끝입니다.

 

 

하지만, 매우 여러가지 단점과 보안에 문제가 있습니다.

• 자격증명이 반복 전송됩니다. 유출 시 피해가 큽니다.
• 로그/리퍼러/프록시 등에서 흔적이 남기 쉽습니다.
• 세션(상태)이 없어 UX가 떨어지고, 권한 변경/로그아웃 제어가 어렵습니다.

내부망 수준이 아니라면 피하는 것이 좋습니다.

 

 

클라이언트 저장(쿠키/스토리지에 id/pw)

매 요청 자격증명을 타이핑하기 불편합니다. 그래서 쿠키/로컬스토리지에 id/pw를 넣어 자동으로 보내는 패턴을 썼습니다.

한 번 로그인하면 계속 요청이 가능하므로 매우 편하게 쓸 수 있습니다. 하지만 그만큼 해커들한테도 편하게 악용이 가능해졌습니다.

• 자격증명 자체를 클라이언트에 저장하므로 XSS·디버거·확장프로그램·물리적 탈취에 취약합니다.
• 사용자 비밀번호 정책, 교체 주기, 유출 감지와 충돌합니다.

자격증명을 클라이언트에 저장하는건 해커들에게 사용자의 정보를 공개할 수 있는 위험이 있으므로 제일 피해야 합니다.

 

 

서버 세션(Session in App Memory)

위 클라이언트에 자격증명을 저장하는 걸 보완하기 위해 서버의 세션 개념이 도입됐습니다. “id/pw 대신 세션ID만 갖고 다니자.” 그리고 웹 통신을 할땐 이 세션 ID 를 주고받자라는 취지입니다.

• 로그인 성공 시 서버가 sessionId를 만들고 서버 메모리(in-memory)에 사용자 상태를 저장합니다. 클라이언트는 쿠키로 sessionId만 보관합니다.

클라이언트에는 민감 정보가 남지 않고, 서버에서 세션 만료/강제 종료/권한 즉시 반영이 가능해졌습니다. 또한 쿠키에 HttpOnly/Secure/SameSite를 붙여 XSS·CSRF 내성을 강화할 수 있습니다.

클라이언트에 자격 증명 정보들을 들고 있는 것보다 매우 유용해졌지만, 몇몇 부족한 사항이 있습니다.

 

• 서버 재기동 시 메모리 세션이 모두 사라집니다.
• 수평 확장 시 문제가 시작됩니다.(단일 인스턴스/소규모 서비스에서만 유용)

 

공유 세션 스토리지

서비스가 잘 되면 서버를 늘립니다. 여기서 세션 일관성 문제가 발생합니다. 사용자는 1번 서버에 로그인을 시도하고, 1번 서버는 사용자에 대한 세션 정보를 메모리에 로드하여 알고 있게 됩니다. 근데 사용자가 다음 요청을보냈을 때 로드밸런서에 의해 2번 서버에 요청이 갔다면, 2번 서버는 사용자의 세션 정보를 알수 없기 때문에  401 에러는 반환할 것입니다. 분명 사용자는 이미 로그인을 했는데도 말이죠. 

 

 

이걸 해결하기 위해 1번 서버에 로그인한 사용자라면 앞으로 계속 1번 서버로 요청을 라우팅할 수 있습니다. 스티키 세션(세션 어피니티) 덕분에  당장의 세션 정보를 못찾는 문제를 해결할 수 있습니다. 하지만, 여전히 문제점이 있습니다. 

 

• 해당 서버가 내려가면 세션 유실.
• 트래픽 쏠림·스케일 인/아웃 시 상태 이동이 어렵습니다.

 

이를 극복하기 위해 나온 개념이 공유 세션 스토리지입니다. 세션을 서버에 메모리에 각각 저장하는 것이 아닌, 외부 저장소(보통 Redis) 에 보관합니다. 모든 서버가 같은 저장소를 조회합니다.

• 어느 서버로 가든 세션정보를 조회할 수 있습니다. → 수평 확장 용이.
• 세션 만료/강제 종료/블랙리스트 관리가 쉽습니다.

하지만, 공유 세션 스토리지를 도입하게 되므로써 따라오는 단점과 새과제도 생겼습니다. 

 

• 세션 저장소가 핫 스팟/단일 장애 지점(SPOF) 가 됩니다 → 클러스터링, 복제, 모니터링 필수.
• 모든 요청이 외부 저장소를 거치면 레이턴시·비용 증가.
• 대규모 트래픽에서 세션 I/O가 병목이 될 수 있습니다.

 

토큰 기반(Stateless)으로 전환

HTTP 프로토콜 자체가 무상태성을 기반으로 설계되었습니다. 간단하게 무상태성이란 서버가 클라이언트의 이전 요청 상태를 보존하지 않는 특성을 말합니다. 서버는 매 요청을 독립적인 것으로 간주하며, 이전 요청의 맥락이나 세션을 기억하지 않습니다. 하지만 공유 세션 스토리지는 사용자의 세션 정보를 서버에 저장하기 때문에 무상태성에 어긋납니다. 

“세션 상태를 중앙에 두는 대신, 서명된 토큰으로 인증 정보를 들고 다니자.” 라는  개념으로 나온 기술이 토큰 기반 인증 인가입니다.

서버가 로그인 시 시크릿 키를 기반으로 서명된 Self-contained Token를 발급합니다. 이후 요청들은 서버에서 내부 저장소 조회 없이 시크릿 키로 토큰 서명 검증만으로 인증을 끝냅니다.

 

Self-Contained Token (자가 포함 토큰)

Self-contained 토큰은 인증과 인가에 필요한 모든 정보를 별도의 조회 서비스 없이 토큰 자체에 담고 있는 데이터 구조입니다. 보통 JWT(JSON Web Token) 형태로 사용됩니다. 이러한 토큰은 디지털 서명이 되어 있기 때문에, 수신 서버는 외부 조회 없이 토큰의 무결성을 검증하고 사용자 신원과 권한(클레임)을 추출할 수 있습니다. 토큰 자체로는 해독하기 쉬워 비밀번호 같은 정보들을 담지는 않습니다. 이름, 만료 기한, 권한등의 정보를 넣을 수 있습니다.

 

Self-Contained Token의 동작 방식

 

1. 발급(Issuance)
   • 사용자가 인증에 성공하면, 서버가 클라이언트에게 self-contained 토큰을 발급합니다.
2. 내용(Contents)
   • 토큰에는 사용자 또는 클라이언트의 신원, 권한, 그리고 기타 메타데이터가 포함되며, 토큰의 구조 안에 인코딩됩니다.
3. 전달(Verification)
   • 클라이언트는 발급받은 토큰을 API 요청에 함께 전송합니다. (주로 Authenticate 헤더) 
4. 서버 측 검증(Server-Side Validation)
   • 리소스를 받는 서버는 토큰의 서명을 직접 검증하고, 내부에 담긴 클레임을 추출하여 사용자의 신원을 확인하고 접근 권한을 허용하거나 거부합니다.

 

 

외부 세션 저장소가 필요 없으므로 레이턴시·비용 절감, 장애면적을 축소할 수 있다는 장점이 있습니다. 또한  서버를 무한히 늘려도 그 서버 자체에서 시크릿 키로 검증만 하면 되므로 서버 수평 확장에 최적입니다.

 

하지만, 이에 따른 문제점도 있죠.

 

• 탈취되면 만료 전까지 막기 어렵습니다(서버가 상태를 들고 있지 않기 때문).
• 즉시 강제 로그아웃/권한박탈이 어렵습니다(이미 발급된 토큰은 유효).
• 토큰 크기가 커지면 헤더 비용이 증가합니다.

이 문제를 해결하기 위해 토큰도 Access Token과 Refresh Token으로 나누고, 인증인가 방식도 하이브리드 형식을 사용하도록 바뀌었습니다.

 

Access Token

Access Token은 사용자가 인증에 성공했을 때 발급되는 짧은 수명의 토큰으로, 리소스에 접근(API)할 때 매 요청마다 포함됩니다.

• 클라이언트는 API 호출 시 Authorization: Bearer <access_token> 헤더에 담아 전송합니다.
• 탈취 위험이 있기 때문에 보통 수명이 짧습니다. (5분~15분 정도 권장) 
• 서버는 추가 조회 없이 토큰 서명만 검증하면 권한 확인 가능합니다.

이렇게 Access Token 을사용하게 되면 무상태성을 보장하게 되고, 불필요한 세션 스토리지 조회도 할 필요가 없는 것이죠.

 

 

Refresh Token

Refresh Token은 Access Token이 만료되었을 때, 새로운 Access Token을 발급받기 위해 사용하는 갱신 요청 토큰입니다.

• 일반적으로 서버 측 저장소(예: Redis, DB)에 기록하여 관리합니다.
• 클라이언트는 Refresh Token을 보관하고 있다가 Access Token이 만료되면 재발급 요청을 합니다.
• 수명은 길게 설정합니다. (며칠 ~ 몇 주)
• 보안 강화를 위해 Refresh Token 회전(Rotation) 기법을 씁니다. → 재발급 시마다 새로운 Refresh Token 발급, 기존 것은 즉시 폐기. 이전 RT가 다시 오면 탈취로 간주하고 전체 세션을 무효화합니다.

 

이렇게 Access Token 과 Refresh Token을 활용한 토큰 기반 인증인가는 비교 보안과 편의성의 균형을 맞출 수 있었습니다. 하지만 RT 저장소는 결국 또 하나의 중앙상태입니다. 다만 접근 빈도가 낮고, Access 검증은 여전히 무상태라 병목이 크게 줄어듭니다.

 

OAuth 2.0

여러 가지 웹서비스가 발전하면서, 다른 애플리케이션의 기능을 활용하는 서비스도 점점 많아졌습니다. 예를 들어, A 서비스가 구글 캘린더와 연동해 사용자의 일정을 통합 관리하는 기능을 제공한다고 가정해 보겠습니다. 이 경우 A 서비스는 사용자의 구글 캘린더에 접근할 수 있는 권한이 필요합니다.

과거 방식이라면 A 서비스가 사용자의 구글 계정 ID와 PW를 직접 받아 저장하고, 이를 통해 구글 캘린더에 접근하는 식으로 구현했습니다. 하지만 이 방식에는 치명적인 문제가 있습니다.

 

• 보안 위험
  사용자의 구글 계정 ID/PW를 A 서비스가 직접 보관하기 때문에, 유출 시 구글 캘린더뿐 아니라 구글 드라이브, 지메일 등 모든 리소스가 위험에 노출됩니다.
  
  
• 서비스 운영 부담
  A 서비스 입장에서도 타사 서비스 계정을 직접 보관한다는 것은 큰 부담입니다. 보안사고가 발생하면 서비스 자체가 신뢰를 잃고 존속하기 어려워집니다.
  
  
• 플랫폼 제공자 입장
  구글 같은 서비스 제공자 입장에서도 강력한 보안 체계를 마련했더라도, 제3자 애플리케이션이 비밀번호를 보관하는 순간 모든 노력이 무용지물이 됩니다.

이러한 문제를 해결하기 위해 등장한 것이 OAuth 2.0입니다. 핵심 아이디어는 인증(Authentication)은 서비스 제공자가 직접 하고, 인가(Authorization, 권한 위임)는 제3자 애플리케이션이 위임받도록 분리하는 것입니다.

 

 

OAuth 2.0 에 대한 자세한 내용은 아래 블로그 글에 따로 정리해 두었습니다.

 

왜 “세션 스토리지(공유 세션)”가 나왔고, 왜 “토큰”으로 갔는가?

 

배경/문제	선택	해결한 것	대가 및 부작용
단일 서버 UX·보안 향상 필요	서버 세션(in-memory)	id/pw를 들고 다니지 않음, 만료/강제 로그아웃 가능	재기동 시 세션 유실, 수평 확장 한계
다중 서버/로드밸런서	공유 세션 스토리지(Redis/DB)	서버 간 세션 일관성	저장소가 병목/핫스팟, 모든 요청 I/O 증가
서버가 상태성을 가짐	토큰(JWT)	무상태 검증, 무한 수평 확장, 외부 저장소 제거	즉시 회수 어려움, 탈취 위험 → RT 회전/블랙리스트로 보완
외부 자원 접근/SSO	OAuth2 / OIDC	인증·인가 분리, 비밀번호 비보관, 범위 기반 접근	프로토콜 복잡성, 보안 파라미터 준수 필요

결국 트래픽·확장성·보안 목표가 기술 선택을 하게 됐습니다.

• 공유 세션은 “멀티 서버의 첫 고비”를 넘기기 위한 합리적 타협이었습니다.
• 토큰은 “글로벌 확장성과 무상태성”을 위한 다음 단계였습니다.
• OAuth/OIDC는 “타 서비스와의 안전한 위임과 통합”을 위한 표준이었습니다.