흔히 구글로 로그인 할 때 OAuth2.0을 쓴다고 한다. 하지만 엄밀히 말하면 OAuth2.0위에서 동작하는 OIDC를 사용하고 있는 것이다. 둘은 어떻게 다른걸까?
OAuth2.0이란?
1) 등장배경
OAuth2.0이 없던 시절에는 예를 들어 제3자앱에서 사용자의 구글 드라이브에 접근하려면 구글 ID와 비밀번호를 입력 받아야했다. 이는 다음과 같은 문제들이 있었다.
-
비밀번호 노출: 서비스가 내 비밀번호를 저장하고 있어야 함
-
권한 제어 불가: "파일 읽기"만 허용하고 싶은데, 비밀번호를 주면 "메일 삭제"까지 가능해짐
-
비밀번호 변경 시 마비: 구글 비번을 바꾸면 연결된 모든 앱이 끊김
이 문제를 해결하기 위해 비밀번호 대신 정해진 권한이 담긴 토큰을 주자는 아이디어가 OAuth2.0의 핵심이다.
2) Roles
-
Resource Owner (사용자): 데이터의 주인인 "나"
-
Client (나의 서비스): 구글 데이터를 쓰고 싶어 하는 백엔드 앱(news-summary, community-space 등)
-
Authorization Server (인증 서버): 권한을 부여해주는 서버(Google, Kakao)
-
Resource Server (리소스 서버): 실제 데이터가 있는 서버(Google Drive API, Kakao Profile API)
3) Scope
scope: 허용된 권한의 범위
클라이언트가 "나는 이 사용자의 email과 profile 권한만 필요해"라고 요청
-> 사용자는 동의 화면에서 해당 항목만 체크하여 허가
-> 발급된 Access Token에는 오직 그 권한 정보만 숨겨져 있음
4) 한계
Access Token의 특징:
- 보통 의미 없는 문자열(Opaque Token)인 경우가 많다. (예: ya29.a0AfH6S...)
- 백엔드 서버는 이 토큰만 보고는 "이 사용자가 누구인지(이메일이 뭔지, 이름이 뭔지)" 알 수 없다.
- 정보를 알기 위해 다시 한번 Resource Server에 "이 토큰 줄 테니 사용자 정보 좀 알려줘"라고 물어봐야 합니다.
-> 즉, OAuth 2.0은 '권한'은 주지만 '신원'은 불분명하게 전달해서 토큰을 줄 때 처음부터 신원도 함께 달라는 요구가 생겼고, 그래서 탄생한 것이 바로 ID Token을 포함하는 OIDC이다.
OIDC는 OAuth 2.0이라는 튼튼한 집 위에 '인증(Authentication)'이라는 층을 한 층 더 올린 표준 프로토콜
OIDC = OAuth 2.0 + ID Token (JWT)
OAuth 2.0이 "이 열쇠로 내 방에 들어와도 돼"라고 말한다면, OIDC는 그 열쇠와 함께 "내 이름과 사진이 박힌 신분증"을 같이 주는 것과 같다.
| 구분 | OAuth 2.0 | OIDC (OpenID Connect) |
|---|---|---|
| 주요 목적 | 인가 (Access Delegation) | 인증 (Identity Verification) |
| 발행 토큰 | Access Token (사용자 정보 없음) | ID Token (JWT, 사용자 정보 포함) |
| 핵심 질문 | 이 앱이 내 데이터를 써도 될까? | 이 사용자가 누구인가? |
| 엔드포인트 | 서비스마다 다름 | UserInfo 엔드포인트 표준화 |
5) 왜 OIDC가 백엔드 개발자에게 좋을까?
-
표준화된 사용자 정보: 구글이든 카카오든 sub(고유 식별자), email, name 같은 클레임 형식이 통일되어 있어 로직 구현이 편하다.
-
보안 강화: JWT 기반의 ID Token을 통해 서버 측에서 위변조 여부를 즉시 확인 가능
-
상태 확인: nonce나 state 같은 파라미터를 통해 요청이 중간에 가로채기 당했는지 검증하기가 훨씬 쉬움
