Authentication(인증) vs Authorization(인가)
🔑 Authentication vs Authorization 한 줄 정리
- Authentication(인증): 너 누구야?
- Authorization(인가): 뭘 해도 되는 사람인가?
🧩 아래 정리를 하고 깨달은 점!
- 인증은
본인이 맞는지 확인하는 과정이다.
→ 로그인, 비밀번호 확인, AccessToken 검증 등이 모두 인증에 속한다. - 인가는
무엇을 할 수 있는지 권한을 확인하는 과정이다.
→ 내 정보만 보기, 게시글 수정 가능 여부, 관리자 전용 페이지 접근 등이 인가다. - 인증이 먼저 이루어져야 인가를 할 수 있다.
→ 누구인지 모르면 권한을 체크할 수도 없다. - HTTP는
Stateless라서, 인증 상태를 서버가 기억하지 않는다.
→ 클라이언트가 매 요청마다 토큰을 보내야 하는 이유 - AccessToken이 하는 핵심 역할은
요청한 사용자가 누구인지서버에 증명하는 것. - 서버는 사용자가 누구인지 알게 된 뒤, 권한에 따라 접근을 허용하거나 차단한다.
Authentication(인증)이란?
Authentication = Identity(정체성)
인증은 사용자의 정체성을 확인하는 과정이다.
인증의 대표적인 예시
- 이메일 + 비밀번호로 로그인
- OAuth 소셜 로그인
- AccessToken 검증 (서명 및 만료 여부 확인)
- RefreshToken을 이용한 재발급 요청
인증이 끝나면 서버는 아래 정보를 얻게 된다:
- 이 사용자의 ID (ex: user_id: 24)
- 어떤 계정인지 (ex: email: test@gmail.com)
- 토큰이 유효한지 여부
아직 이 사람이 무엇을 할 수 있는지는 모른다. 그건 인가 단계에서 처리된다!
Authorization(인가)이란?
Authorization = Permissions(권한)
인가란 인증된 사용자가 무엇을 할 수 있는지 확인하는 과정이다.
예를 들어:
- 내가 다른 사람의 글을 수정하려고 시도할 때
- 일반 유저가 admin 페이지에 접근하려고 할 때
- 주문 ID를 조회할 때 → 이 주문이 내 것인가?
인가 판단을 위해 서버가 확인하는 정보
- 권한(Role): admin, user, seller 등
- 리소스 소유 여부: 글 작성자와 현재 사용자 ID 비교
- 정책 기반 권한(Policy)
- RBAC(Role-Based Access Control)
- ABAC(Attribute-Based Access Control)
💡 Identity / Permissions
- Identity(정체성): 나는 누구인가
- Permissions(권한): 무엇을 할 수 있는가
401 vs 403
이 둘의 차이를 이해하면 인증/인가를 완전히 이해한 것과 같다.
401 Unauthorized - 인증 실패
- AccessToken이 없거나
- AccessToken이 만료되었거나
- 토큰 서명이 위조되었거나
즉, 네가 누구인지 모르겠어. 인증 먼저 해!
→ refreshToken으로 새 AT 재발급 시도
→ 실패 시 로그인 페이지로 이동
403 Forbidden — 인가 실패
- 토큰은 유효함 (누군지는 안다)
- 하지만 권한이 없음
예:
- 일반 유저가 /admin 접근
- 나 말고 다른 사용자의 글 삭제 시도
- 고객이 다른 고객의 주문 정보 조회
즉, 누군지는 알겠는데, 그 행동은 하면 안 돼!
인증/인가 흐름 이해하기
1. 사용자가 요청을 보냄
http
GET /users/123/profile
Authorization: Bearer <token>2. 서버는 인증을 먼저 수행
- 토큰 유효? O
- 만료됨? X
- 서명 위조? X
→ 인증 OK
3. 그 다음 인가 수행
- user_id=123 프로필 접근 → 본인인가?
- 아니면 관리자 권한이 있는가?
4. 결과
- 인가 통과 → 요청 처리
- 인가 실패 → 403 Forbidden
💡 인증 → 인가 순서가 중요한 이유
서버는 반드시 이렇게 진행한다:
plaintext
[1] Authentication (사용자가 누구인지 확인)
[2] Authorization (무엇을 할 수 있는지 확인)인증 없이 인가를 할 수 없다.
→ 누군지도 모르는데 “이 글 수정 가능해요?”라고 물어볼 수 없음!
→ 토큰이 없는데 admin 권한인지 판단할 수 없음!
JWT 기반 인증/인가 예시
AccessToken 안에는 이런 정보가 들어있다:
json
{
"sub": "123",
"role": "admin",
"exp": 1739421234
}이처럼 하나의 토큰 안에 누구인지(sub)와 어떤 권한을 가졌는지(role)를 함께 담아두고, 서버는 이 정보를 기준으로 인증과 인가를 한 번에 처리한다.
sub → 인증 정보
→ user 123이 보낸 요청입니다.role → 인가 정보
→ 이 사용자는 admin이다.
서버는 토큰을 파싱해서 두 가지를 모두 처리해야 한다.
- 서명 검증 (인증)
- role 확인 (인가)
인증 / 인가 비교
| 구분 | Authentication (인증) | Authorization (인가) |
|---|---|---|
| 질문 | “너 누구야?” | “너 이 작업을 할 수 있어?” |
| 역할 | 신원 확인 | 권한 검증 |
| 예시 | 로그인, AccessToken 검증 | Admin 권한 확인, 게시글 수정 가능 여부 |
| 적용 시점 | 요청의 초반부 | 인증 완료 후 이어지는 단계 |
| 실패 시 상태 코드 | 401 Unauthorized | 403 Forbidden |
| 무엇이 필요한가 | 토큰/세션/계정 정보 | Role, Policy, ACL, 권한 테이블 |
정리
💡 요약
- 인증 없이 인가는 없다.
- JWT는 인증 + 인가 정보를 함께 담을 수 있다.
- 인증 실패 → 401
- 인가 실패 → 403
- HTTP는 Stateless이므로, 인증 정보를 매 요청마다 보내야 한다.