소셜 로그인 이해하기: OAuth 2.0 흐름과 Access Token 발급 과정 정리

우리가 자주 사용하는 로그인 방식 중 하나가 소셜 로그인입니다. 구글로 로그인, 카카오로 로그인. 네이버로 로그인과 같은 버튼 하나를 클릭하면 별도의 회원가입 없이 빠르게 로그인이 가능합니다. 이 소셜 로그인은 대부분 OAuth 2.0 이라는 표준 프로토콜 위에서 동작합니다. 이번 글에서는 OAuth 2.0이 어떤 흐름으로 동작하는지, 그리고 Access Token이 어떻게 발급되는지 쉽게 이해할 수 있도록 정리합니다.

소셜 로그인이 필요한 이유

이유	설명
회원가입 부담 감소	이메일 입력, 비밀번호 생성 절차 없이 바로 로그인 가능
사용자 경험 개선	로그인 유지, 기기 간 연결 등 UX 향상
비밀번호 저장 불필요	서비스가 비밀번호를 직접 보관하지 않아 보안 위험 감소

서비스 제공자의 입장에서도 보안 부담을 줄일 수 있다는 점에서 이점이 큽니다.

OAuth 2.0의 핵심 개념

OAuth는 "권한 위임" 모델입니다. 사용자 정보를 가진 서비스(예: 구글, 카카오)는 인증을 담당하고 우리 서비스는 해당 사용자 정보를 정상적으로 요청할 수 있는 권한을 위임받는 방식입니다. 이때 필요한 것이 Access Token 입니다.

아래 흐름을 하나씩 생각해보면 어렵지 않습니다.

사용자가 "구글 로그인" 버튼을 클릭합니다.
우리 서비스는 사용자를 구글 로그인 페이지로 이동시킵니다.
사용자는 구글 계정으로 로그인하고, 데이터 제공 여부를 승인합니다.
구글은 우리 서비스에게 Authorization Code 를 전달합니다.
우리 서비스 서버는 이 코드를 사용해 구글 서버에서 Access Token 을 요청합니다.
Access Token을 발급받은 뒤, 이를 사용해 사용자 정보를 요청할 수 있게 됩니다.

이러한 흐름을 통해 Access Token을 통해 사용자 정보를 안전하게 요청할 수 있습니다.

Access Token과 Refresh Token

API 인증 과정에서 사용자는 주로 Access Token과 Refresh Token 두 가지 토큰을 사용합니다. 두 토큰은 각각의 목적과 유효 기간이 다르며, 함께 사용함으로써 보안성과 사용자 편의성을 모두 확보할 수 있습니다.

토큰 구분	역할	유효 기간
Access Token	API 요청 시 인증 수단으로 사용	짧음
Refresh Token	Access Token 재발급 시 사용	김

Access Token은 실제 API 호출 시 인증 수단으로 사용되기 때문에, 만약 외부에 노출되거나 탈취되었을 경우 곧바로 시스템 접근이 가능해집니다. 따라서 Access Token의 유효 기간을 짧게 설정하여, 토큰이 유출되더라도 피해를 최소화하도록 설계합니다.

Access Token의 유효 기간이 짧다는 점은 보안상 이점이 있지만, 사용자 입장에서는 토큰이 만료될 때마다 매번 재로그인해야 하는 불편함이 발생할 수 있습니다. 이 문제를 해결하기 위해 Refresh Token이 사용됩니다. Refresh Token은 유효 기간이 길며, 만료된 Access Token을 재발급 받기 위한 인증 수단으로 동작합니다. 이를 통해 사용자는 로그인 상태를 장기간 유지할 수 있고, 시스템은 여전히 짧은 주기의 Access Token을 사용하여 보안을 유지할 수 있습니다.

OpenID Connect(OIDC)와의 관계

OAuth 2.0은 기본적으로 권한 위임(Authorization Delegation)을 위한 프레임워크입니다. 즉, 클라이언트 애플리케이션이 사용자의 자원(API, 데이터 등)에 접근할 수 있도록 허가를 위임받는 과정을 정의합니다. 따라서 OAuth 2.0만으로는 사용자가 누구인지 인증(Authentication) 하는 기능을 직접 제공하지 않습니다. 이 때문에 소셜 로그인(Google, Kakao, Naver 등)과 같은 인증 시나리오에서는 OAuth 2.0 위에 OpenID Connect(OIDC) 프로토콜이 추가로 사용됩니다.

OIDC의 역할

OpenID Connect (OIDC) 는 OAuth 2.0을 확장하여, 인증(Authentication)을 위한 표준화된 방법을 제공합니다. OIDC는 단순히 접근 권한을 위임하는 것을 넘어서, “이 사용자가 누구인지”를 애플리케이션이 신뢰할 수 있는 형태로 전달하는 것이 핵심 목적입니다. 이를 위해 OIDC는 ID Token이라는 개념이 도입됩니다.

ID Token

형태: 일반적으로 JWT (JSON Web Token) 형식으로 인코딩되어 전달됩니다.
내용: 사용자 식별 정보(예: sub, email, name 등)와 토큰의 발급자(iss), 만료 시간(exp) 등의 메타데이터를 포함합니다.
역할: 클라이언트는 이 토큰을 검증함으로써, 별도의 API 호출 없이도 사용자의 인증 상태를 확인할 수 있습니다.

구분	OAuth 2.0	OpenID Connect (OIDC)
목적	권한 위임 (Authorization)	사용자 인증 (Authentication)
주요 토큰	Access Token	ID Token (+ Access Token)
주요 사용처	API 접근 제어	로그인 및 사용자 정보 확인
표준 형태	프레임워크	OAuth 2.0 기반 확장 프로토콜

OAuth 2.0은 “무엇을 할 수 있는가(권한)”에 초점을 맞추고, OpenID Connect는 “누가 하는가(인증)”에 초점을 맞춥니다. 두 프로토콜은 서로 보완 관계에 있으며, 현대의 대부분의 소셜 로그인 및 인증 시스템은 OIDC를 기반으로 구현되어 있습니다.

주의사항

항목	설명
토큰 저장 위치	브라우저 로컬스토리지 대신 httpOnly 쿠키가 안전함
로그아웃	소셜 서비스 로그아웃과 자체 로그아웃의 범위 구분 필요
동일 사용자 매핑	플랫폼마다 이메일 제공 정책이 다를 수 있으므로 주의
OTP, MFA 동시 적용 여부	보안 민감 서비스에서는 추가 인증 고려

소셜 로그인이 편하다고 해서 무조건 위험하거나 무조건 안전한 것은 아닙니다. 구현 방식과 저장 방식이 보안을 결정합니다.

정리

소셜 로그인은 사용자의 로그인 부담을 줄이고 서비스 보안을 개선할 수 있는 방식입니다.
OAuth 2.0은 권한 위임 구조이며 Access Token을 통해 사용자 정보 접근 권한을 가집니다.
소셜 로그인 시에는 OAuth 2.0과 OIDC가 함께 사용됩니다.
토큰 저장 방식과 사용자 매핑 정책은 실무에서 특히 신중해야 합니다.

참고자료

OAuth 2.0 공식 문서: https://oauth.net/2/
OpenID Connect 설명: https://openid.net/connect/
Google OAuth Playground: https://developers.google.com/oauthplayground