- OAuth2와 OpenID Connect(OIDC)의 차이
- OAuth2는 "인가(Authorization)" 프로토콜이다
- OIDC는 OAuth2를 확장하여 "인증(Authentication)"를 포함한다
- 실제 소셜 로그인 시 어떤 데이터가 오고 가는가?
- 두 프로토콜의 워크플로우 차이
OAuth2와 OIDC의 관계
1. OAuth2의 목적
- OAuth2는 인가(Authorization)에 초점을 둠
- 특정 클라이언트 애플리케이션이 사용자를 대신해서 리소스 서버의 데이터(API)에 접근할 수 있는 권한을 부여받는 프로토콜
- 사용자가 캘린더 앱을 통해 구글 캘린더 API에 접근하도록 허용함
2. OIDC(OpenID Connect)의 목적
- OIDC는 OAuth2를 확장한 인증(Authentication) 프로토콜임
- OIDC는 OAuth2의 Access Token 발급 과정에 더해 ID Token(JWT 기반)을 추가로 발급하여 사용자의 인증 정보를 제공함
- OIDC를 사용하면 클라이언트 애플리케이션은 사용자가 누구인지 식별할 수 있음
- OIDC는 우리가 흔히 사용하는 소셜 로그인(Google, Facebook, Github, Okta(옥타))의 기반임
3. 정리
| 구분 | OAuth2 | OIDC |
| 초점 | 인가(Authorization) | 인증(Authentication) + 인가 |
| 주요 토큰 | Access Token | Access Token + ID Token |
| 목적 | 제3자 API 자원 접근 권한 위임 | 사용자 인증 + 자원 접근 |
| 사용 예시 | 캘린더 API 읽기 권한 위임 | 구글 계정으로 로그인 사용자 정보 조회 |
ID토큰의 개념, 활용
1. ID토큰
OIDC가 OAuth2를 확장하면서 추가된 핵심 요소
JWT(JSON Web Token) 형식으로 발급되며, 사용자 인증 결과와 기본 프로필 정보를 포함함
예 : sub(사용자 고유 ID), name, email, picture, 등등..
# JWT 예시
{
"iss": "<https://accounts.google.com>" # 발급자
"sub": "1234567890" # 사용자 고유 식별자
"aud": "my-client-id" # 토큰을 받을 client ID
"exp": 1672531199 # 만료 시간
"iat": 1672527599 # 발급시간
"email": "b1uffer@naver.com" # 사용자 이메일
"name": "B1uffer" # 사용자의 이름
}
2. Access Token과의 비교
| 구분 | Access Token | ID Token |
| 목적 | 보호된 API 리소스 접근 | 사용자 인증 결과 증명 |
| 수신자 | Resource Server | Client 애플리케이션 |
| 형식 | Opaque 또는 JWT | JWT |
| 포함 정보 | 권한 범위(스코프, Scope) | 사용자 식별 정보 |
3. 활용
* Access Token은 API 호출시 헤더에 담아서 사용한다
* ID Token은 로그인 완료 후 애플리케이션이 사용자의 정보를 확인할 때 사용한다
* 구글 로그인 후 ID Token을 디코딩하면, 사용자의 이메일과 이름을 바로 알 수 있음
소셜 로그인 구현과 OIDC
1. OAuth2 기반 동작
* OAuth2는 사용자 데이터 접근 권한 위임에 집중한다. 로그인 여부나 사용자의 신원 자체는 보장하지 않는다
2. OIDC 기반 동작
* OIDC는 Access Token 외에 ID Token을 함께 발급하여 클라이언트가 사용자 인증 정보를 직접 확인할 수 있도록 함
소셜 로그인 시 시나리오
- OAuth2만 사용 : 앱은 Google API를 대신 호출 할 수 있지만 "사용자가 누구"인지는 알 수 없음
- 예 : OAuth2만 사용하면 "사용자의 Google Drive 파일을 읽어올 권한"을 위임함
- OIDC 사용 : 앱은 Google API 접근 권한을 얻는 동시에 사용자의 이름, 이메일, 프로필을 안전하게 전달받음
- 예 : "Google 계정으로 로그인" 버튼 - > 이메일, 이름을 가져와서 회원가입/로그인 처리 + Google Drive 접근
팁
* OAuth2만 사용할 경우 사용자가 누구인지 확인할 수 없다. 단지 "이 사용자가 리소스 접근을 허용했다"라는 사실만 알 수 있다
* OIDC를 사용해야 사용자의 신언과 기본 프로필을 안전하게 가져올 수 있다
* 소셜 로그인(Google, Facebook, Github, Okta 등)은 모두 OIDC를 기반으로 동작한다
* 따라서 외부 API 호출만 필요하다면 OAuth2 / 로그인 기능까지 필요하다면 OIDC를 사용해야 한다
정리
| 항목 | OAuth2 | OIDC |
| 초점 | 인가(Authorization) | 인증(Authentication) + 인가 |
| 주요 토큰 | Access Token | Access Token + ID Token |
| 제공 정보 | API 접근 권한 | 사용자 인증 정보(이메일, 이름 등) |
| 대표 사례 | 캘린더 API 접근 | 구글 로그인, 소셜 로그인 |
'Spring Boot > 유저 관리 기능' 카테고리의 다른 글
| OAuth와 OpenID Connect : OAuth 워크플로우 (0) | 2026.03.24 |
|---|---|
| OAuth와 OpenID Connect : OAuth 주체와 설정 (0) | 2026.03.23 |
| OAuth와 OpenID Connect : OAuth의 개념, 필요성 (0) | 2026.03.23 |
| 인가와 권한 관리 : 세션/토큰 기반 인증에서의 인가 구현 (0) | 2026.03.22 |
| 인가와 권한 관리 : 실제 인가 구현 사례 (0) | 2026.03.21 |