[인증/인가] 로그인 뒤에 숨겨진 구조 이해하기
웹 서비스를 이용하다 보면 로그인은 너무 당연한 기능처럼 느껴진다.
아이디와 비밀번호를 입력하면 바로 서비스에 접속할 수 있고,
어느 순간에는 다시 로그인을 요구받기도 한다.
그동안은 이런 과정들을 자연스럽게 받아들였지만,
직접 구현을 해보려 하다 보니 여러 가지 궁금증이 생기기 시작했다.
로그인 정보는 어디에 저장될까?
왜 일정 시간이 지나면 다시 로그인을 해야 할까?
이러한 질문들을 계기로
로그인 기능 뒤에 숨겨진 구조를 하나씩 살펴보게 되었다.
이번 글에서는 먼저 인증과 인가의 개념을 정리하고,
이후 이를 가능하게 해주는 Cookie, Session, Token에 대해 차례대로 정리해보려고 한다.
먼저 가장 기본이 되는 인증과 인가부터 살펴보자.
인증과 인가는 무엇일까?
인증 (Authentication)
인증은 이 사용자가 누구인지 확인하는 과정이다.
가장 대표적인 예시가 로그인이다.
사용자가 아이디와 비밀번호를 입력하면, 서버는 해당 정보가 실제 계정과 일치하는지 확인한다.
이 과정을 통과하면, 서버는 “이 사용자는 본인이 맞다”고 판단하고 인증을 완료한다.
인증 방식은 하나만 존재하지 않는다.
- 아이디와 비밀번호 인증 ➔ 가장 일반적인 방식
- 생채 인식 ➔ 지문, 얼굴, 홍채 등
- 일회용 코드 (OTP) ➔ 문자, 이메일, 인증 앱 코드 등
최근에는 보안을 강화하기 위해 여러 인증 방식을 함께 사용하는 경우도 있다.
예를 들어, 아이디와 비밀번호 로그인 후 문자나 이메일 인증을 추가하는 방식이 대표적이다.
인가 (Authorization)
인가는 인증된 사용자가 무엇을 할 수 있는지를 결정하는 과정이다.
즉 이미 신원이 확인된 사용자를 대상으로 접근 권한을 판단하는 단계라고 볼 수 있다.
공항을 예로 들면 다음과 같다.
- 여권 검사 ➔ 인증
- 출국 게이트 통과 ➔ 인가
웹 서비스에서도 이와 유사하다.
- 관리자 ➔ 모든 기능 사용 가능
- 일반 사용자 ➔ 제한된 기능만 사용 가능
- 게스트 ➔ 일부 정보만 조회 가능
이처럼 인가는 “이 사용자에게 어디까지 허용할 것인가?”를 결정하는 과정이다.
인증과 인가의 관계
“인증이 먼저 이루어지고, 그 다음 인가가 이루어진다.”
먼저 사용자의 신원을 확인한 뒤, 해당 사용자에게 어떤 권한을 부여할지 결정한다.
- 로그인으로 인증 완료
- 구매, 이벤트 참여, 관리자 기능 접근 가능
이와 같이 인증 이후 인가가 이어진다.
정리하면 인증은 “너 누구야?”, 인가는 “너 뭐 할 수 있어?”에 대한 답이라고 볼 수 있다.
😮 인증과 인가가 왜 중요할까?
인증과 인가는 웹 서비스 보안의 핵심 요소이다.
만약 인증이 없다면
- 아무나 다른 사람 계정으로 접속할 수 있고
- 개인정보가 그대로 노출 될 수 있다
인가가 없다면
- 일반 사용자가 관리자 기능을 사용할 수 있고
- 데이터를 마음대로 수정하거나 삭제할 수도 있다
이러한 상황은 서비스 운영에 치명적이다.
또한 사용자 입장에서도 중요하다.
내 개인정보와 활동 기록이 안전하게 보호되고, 필요한 기능만 사용할 수 있어야 서비스를 신뢰하고 이용할 수 있기 때문이다.
결국 인증과 인가는 시스템 보안 강화, 데이터 보호, 서비스 신뢰도 유지를 위해 반드시 필요한 구조라고 할 수 있다.
서버는 인증된 사용자를 어떻게 기억하고 있을까?
웹 서비스를 이용하다 보면 로그인에 성공한 뒤 페이지를 이동하거나 새로고침을 해도 로그인 상태가 유지되는 것을 볼 수 있다.
하지만 웹 서비스는 HTTP 프로토콜 위에서 동작한다.
HTTP는 기본적으로 Stateless(무상태)한 특성을 가진다.
즉 서버는 이전 요청의 상태를 기억하지 않는다.
이를 상황으로 예를 들어보면 다음과 같다.
1
2
3
4
5
6
7
8
A(서버): 안녕, 너 누구야?
B(유저): 저는 sihyun입니다.
A: 그래 반가워 sihyun아~ [로그인 완료]
(이후 구매 요청)
A: 구매하려고? 너 누군데?
B: 저는 sihyun이고 이 티셔츠 구매하고 싶어요. (다시 신원 설명)
HTTP 환경에서는 매 요청마다 이런 식으로 신원을 다시 증명해야 한다.
서버 입장에서는 모든 요청이 처음 보는 사용자처럼 느껴진다.
매번 서버에 요청할 때마다 다시 로그인해야 한다면
사용자는 서비스를 이용하기 매우 불편할 것이다.
그렇다면 서버는 어떻게 로그인 상태를 유지할 수 있을까?
이 문제를 해결하기 위해 등장한 것이 바로 Cookie, Session, Token이다.
다음 글에서는 각각의 개념과 동작 방식을 하나씩 살펴보자.
👻 잠깐 짚고 가기 - HTTP는 왜 상태를 기억하지 않을까?
HTTP 프로토콜 특징
- 무상태성 (Stateless)
각 요청과 응답은 서로 독립적이다.
서버는 이전 요청에 대한 정보를 저장하지 않는다.
따라서 동일한 클라이언트가 다시 요청하더라도 모든 정보를 다시 전달해야 한다.- 비연결성 (Connectionless)
클라이언트가 요청을 보내면 서버는 응답을 반환한 후 연결을 종료한다.
HTTP/1.1 이후부터는 Keep-Alive를 통해 연결 재사용이 가능해졌지만, 기본 구조는 여전히 비연결 방식이다.- 비연속성
각 요청은 독립적으로 처리되며, 이전 요청의 상태가 다음 요청에 직접적인 영향을 주지 않는다.
Stateless vs Stateful
- Stateless : 서버가 클라이언트 상태를 저장하지 않음
- Stateful : 서버가 클라이언트 상태를 저장함