인증/인가 개념 정리

인증/인가 핵심 개념 정리: Session, JWT, OAuth 2.0, OpenID Connect

백엔드 개발을 공부하다 보면 인증, 인가, 세션, JWT, OAuth 2.0, OpenID Connect 같은 용어를 자주 접하게 된다.
각 개념은 서로 연결되어 있지만 역할과 목적은 분명히 다르다.
이번 글에서는 이 개념들을 한 번에 정리해보려고 한다.

1. 인증(Authentication)과 인가(Authorization)

먼저 가장 기본이 되는 개념은 인증과 인가이다.

인증(Authentication) 은 사용자가 누구인지 확인하는 과정이다.
예를 들어 아이디와 비밀번호를 검증하거나, 소셜 로그인을 통해 사용자의 신원을 확인하는 과정이 인증에 해당한다.

인가(Authorization) 는 인증된 사용자가 어떤 리소스에 접근할 수 있는지, 어떤 작업을 수행할 수 있는지 결정하는 과정이다.
예를 들어 일반 사용자는 게시글 조회만 가능하고, 관리자는 삭제까지 가능하다면 이것은 인가의 문제다.

정리하면 다음과 같다.

• 인증: 사용자가 누구인지 확인
• 인가: 확인된 사용자가 무엇을 할 수 있는지 결정

예를 들어 로그인은 인증이고, 관리자 페이지에 들어갈 수 있는지 확인하는 것은 인가이다.

---

2. Session 방식과 JWT 방식의 차이

인증 상태를 유지하는 대표적인 방식으로는 Session 기반 방식과 JWT 기반 방식이 있다.

Session 방식

세션 방식은 서버가 사용자 인증 상태를 직접 저장하고 관리하는 방식이다.
클라이언트는 보통 세션 ID만 가지고 있고, 요청을 보낼 때마다 이 세션 ID를 함께 전송한다.
서버는 전달받은 세션 ID를 바탕으로 세션 저장소를 조회해 사용자를 식별한다.

즉, 실제 사용자 상태 정보는 서버에 저장되고, 클라이언트는 그 상태를 식별할 수 있는 키만 들고 있는 구조이다.

JWT 방식

JWT 방식은 서버가 토큰을 발급하고, 클라이언트가 이 토큰을 저장한 뒤 매 요청마다 함께 보내는 방식이다.
서버는 JWT의 서명을 검증해 토큰이 위변조되지 않았는지 확인하고, 그 안에 담긴 정보를 바탕으로 사용자를 식별한다.

이 방식은 별도의 세션 저장소를 두지 않아도 되기 때문에 stateless한 구조를 설계하기에 유리하다.

차이 정리

세션 방식은 서버가 상태를 관리하므로 stateful 하다.
반면 JWT 방식은 서버가 별도의 세션 상태를 저장하지 않고도 인증을 처리할 수 있어 stateless 하다.

각 방식은 다음과 같은 특징이 있다.

세션 방식의 장점

• 서버에서 상태를 직접 관리하므로 제어가 쉽다
• 로그아웃이나 강제 만료 처리가 비교적 쉽다

세션 방식의 단점

• 서버에 세션 저장소가 필요하다
• 서버가 여러 대일 경우 세션 공유 전략이 필요할 수 있다

JWT 방식의 장점

• 서버가 세션 상태를 저장하지 않아도 된다
• 분산 환경이나 확장성이 중요한 구조에서 유리하다

JWT 방식의 단점

• 한 번 발급된 토큰은 만료 전까지 제어가 어렵다
• 토큰 탈취 시 만료 전까지 악용될 수 있다
• 로그아웃이나 강제 만료 처리가 상대적으로 까다롭다

---

3. JWT란 무엇인가

JWT는 JSON Web Token의 약자이며, 클레임 정보를 안전하게 전달하기 위한 토큰 형식이다.
보통 JWT는 다음과 같이 세 부분으로 구성된다.

• Header
• Payload
• Signature

Header

Header에는 토큰 타입과 서명 알고리즘 같은 메타데이터가 들어간다.
예를 들어 typ: JWT, alg: HS256 같은 정보가 포함될 수 있다.

Payload

Payload에는 클레임(claim)이 들어간다.
클레임은 사용자 식별자, 권한, 토큰 만료 시간 등 토큰에 담고 싶은 정보이다.

Signature

Signature는 Header와 Payload를 바탕으로 secret key 등을 사용해 생성한 서명값이다.
서버는 요청이 들어왔을 때 Signature를 다시 계산해 비교함으로써 토큰이 위변조되지 않았는지 검증할 수 있다.

즉, JWT의 핵심은 서명을 통해 무결성을 검증하는 것이다.

다만 한 가지 주의할 점이 있다.
JWT의 Payload는 암호화되는 것이 아니라 보통 인코딩되는 것이기 때문에, 민감한 정보를 그대로 넣는 것은 위험하다.

---

4. OAuth 2.0이란 무엇인가

OAuth 2.0은 사용자의 자격 증명을 클라이언트가 직접 다루지 않고, 사용자를 대신해 보호된 리소스에 접근할 수 있도록 해주는 인가 프레임워크이다.

여기서 중요한 점은 OAuth 2.0은 본질적으로 인증보다는 인가에 초점이 맞춰져 있다는 것이다.

주요 구성 요소는 다음과 같다.

• Resource Owner: 사용자
• Client: 사용자를 대신해 리소스 접근을 요청하는 애플리케이션
• Authorization Server: 사용자 인증 및 토큰 발급을 담당하는 서버
• Resource Server: 실제 보호된 리소스를 가지고 있는 서버

대표적인 동작 흐름: Authorization Code Flow

1. 사용자가 클라이언트에서 로그인이나 권한 요청을 시작한다.
2. 클라이언트는 사용자를 Authorization Server로 리다이렉트한다.
3. 사용자는 Authorization Server에서 로그인하고, 필요한 권한에 동의한다.
4. Authorization Server는 클라이언트에게 authorization code를 전달한다.
5. 클라이언트는 이 code를 Authorization Server에 보내 access token을 발급받는다.
6. 클라이언트는 발급받은 access token으로 Resource Server의 보호된 자원에 접근한다.

즉, OAuth 2.0은 클라이언트가 사용자의 비밀번호를 직접 받지 않고도 권한을 위임받아 리소스에 접근할 수 있게 해주는 구조라고 볼 수 있다.

---

5. OpenID Connect(OIDC)란 무엇인가

OpenID Connect는 OAuth 2.0 위에 인증 기능을 추가한 프로토콜이다.

OAuth 2.0이 주로
“이 클라이언트가 무엇에 접근할 수 있는가?”
를 다룬다면,

OpenID Connect는
“이 사용자가 누구인가?”
를 다룬다.

OAuth 2.0과 OIDC의 차이

OAuth 2.0에서는 보통 클라이언트가 access token을 받아 리소스 서버 접근에 사용한다.

반면 OIDC에서는 access token과 함께 ID token도 받는다.
이 ID token에는 사용자의 식별 정보와 인증 결과가 담겨 있다.

클라이언트는 이 ID token을 검증함으로써 사용자가 누구인지 확인할 수 있고, 그 결과를 바탕으로 자체 로그인 세션을 생성할 수 있다.

즉, OIDC의 핵심은 다음과 같다.

• OAuth 2.0: 인가
• OpenID Connect: 인가 + 사용자 인증 정보 제공

그래서 소셜 로그인에서 “구글 계정으로 로그인”, “카카오로 로그인” 같은 기능은 보통 OIDC 개념이 함께 들어간다고 이해하면 된다.

---

6. 정리

지금까지의 내용을 간단히 정리하면 다음과 같다.

• 인증(Authentication): 사용자가 누구인지 확인하는 것
• 인가(Authorization): 인증된 사용자가 무엇을 할 수 있는지 결정하는 것
• Session: 서버가 인증 상태를 저장하는 방식
• JWT: 서명된 토큰을 통해 인증 정보를 전달하는 방식
• OAuth 2.0: 사용자를 대신해 자원 접근 권한을 위임받는 인가 프레임워크
• OpenID Connect: OAuth 2.0에 사용자 인증 개념을 추가한 프로토콜

이 개념들은 따로 떨어져 있는 것이 아니라 실제 서비스에서 함께 사용되는 경우가 많다.
예를 들어 소셜 로그인에서는 OAuth 2.0과 OIDC를 활용해 외부 인증을 처리하고, 이후 내부 서비스에서는 자체 세션이나 JWT를 사용해 로그인 상태를 유지할 수 있다.

---

7. 마무리

인증과 인가는 비슷해 보이지만 목적이 다르고, Session과 JWT도 각각 장단점이 분명하다.
또 OAuth 2.0과 OpenID Connect는 이름이 비슷해서 헷갈리기 쉽지만, OAuth 2.0은 인가, OIDC는 인증까지 포함한다는 점에서 차이가 있다.

이 개념들을 정확히 구분해두면 로그인 시스템이나 API 보안 구조를 이해할 때 훨씬 도움이 된다.