OAuth 2.0 동작 원리 완벽 정리 - 10분만에 이해하는 소셜 로그인 인증 구조

OAuth 2.0 동작 원리 완벽 정리 - 10분만에 이해하는 소셜 로그인 인증 구조

"구글로 로그인", "카카오톡으로 시작하기" 버튼을 한 번쯤은 눌러보셨을 거예요. 이 편리한 소셜 로그인의 핵심 기술이 바로 OAuth 2.0입니다. 이번 글에서는 OAuth 2.0의 동작 원리를 실전 예제와 함께 쉽게 풀어드릴게요.

OAuth 2.0이란? 왜 필요할까요?

OAuth 2.0은 사용자가 비밀번호를 직접 공유하지 않고도, 다른 애플리케이션에 자신의 정보 접근 권한을 안전하게 위임할 수 있는 인증 표준 프로토콜이에요.

예를 들어 여러분이 만든 서비스에서 사용자의 구글 캘린더 정보가 필요하다면, 사용자에게 구글 아이디와 비밀번호를 직접 받는 게 아니라 OAuth 2.0을 통해 "캘린더 읽기 권한만" 안전하게 받을 수 있죠.

핵심 용어 4가지

• Resource Owner(리소스 소유자): 자원의 주인, 즉 사용자
• Client(클라이언트): 권한을 요청하는 우리 애플리케이션
• Authorization Server(인증 서버): 권한을 부여하는 서버 (예: 구글 로그인 서버)
• Resource Server(리소스 서버): 실제 자원을 제공하는 서버 (예: 구글 API 서버)

OAuth 2.0 인증 흐름 - Authorization Code Grant

가장 많이 사용되는 Authorization Code Grant 방식의 동작 원리를 단계별로 살펴볼게요.

1단계: 사용자가 로그인 버튼 클릭

// 클라이언트에서 인증 요청 URL 생성
const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/callback&
  response_type=code&
  scope=profile email`;

window.location.href = authUrl;

2단계: 사용자가 권한 승인 → 인증 코드 발급
사용자가 구글 로그인 페이지에서 권한을 승인하면, 인증 서버는 redirect_uri로 Authorization Code를 전달해요.

3단계: Authorization Code로 Access Token 교환

// 백엔드에서 Access Token 요청
const response = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    code: authorizationCode,
    client_id: YOUR_CLIENT_ID,
    client_secret: YOUR_CLIENT_SECRET,
    redirect_uri: 'https://yourapp.com/callback',
    grant_type: 'authorization_code'
  })
});

const { access_token } = await response.json();

4단계: Access Token으로 API 호출
발급받은 Access Token을 헤더에 담아 리소스 서버에 요청하면 사용자 정보를 받을 수 있어요.

4가지 Grant Type 비교

OAuth 2.0은 상황에 따라 4가지 인증 방식을 제공해요.

• Authorization Code: 가장 안전, 서버 사이드 애플리케이션에서 사용
• Implicit: 클라이언트 사이드 전용 (현재는 보안상 권장 안 함)
• Resource Owner Password Credentials: 신뢰할 수 있는 앱에서만 사용 (자사 앱)
• Client Credentials: 서버 간 통신, 사용자 개입 없음

실무에서는 Authorization Code 방식을 90% 이상 사용하고, 추가로 보안을 강화한 PKCE(Proof Key for Code Exchange) 방식을 모바일/SPA에서 적용하는 추세예요.

Access Token vs Refresh Token

• Access Token: 실제 API 호출에 사용, 짧은 유효기간 (1시간 내외)
• Refresh Token: Access Token 재발급용, 긴 유효기간 (2주~무제한)

Access Token이 만료되면 Refresh Token으로 재발급 받아요. 이렇게 이중 토큰 구조로 보안성을 높입니다.

실무 구현 시 주의사항

CSRF 공격 방지를 위해 state 파라미터를 반드시 사용하세요. 인증 요청 시 랜덤한 state 값을 생성하고, 콜백에서 동일한 값이 돌아오는지 검증해야 해요. 또한 client_secret은 절대 프론트엔드에 노출되면 안 되며, 반드시 백엔드 서버에서 관리해야 합니다.

마치며

OAuth 2.0은 복잡해 보이지만, "사용자 비밀번호 대신 임시 열쇠(Access Token)를 발급받아 쓴다"는 핵심만 기억하면 이해하기 쉬워요. Authorization Code Grant 방식의 흐름을 손으로 한 번 그려보시면 훨씬 명확해질 거예요. 다음 프로젝트에서 소셜 로그인을 구현할 때 이 글이 도움이 되길 바랍니다!

---

추천 롱테일 키워드

• OAuth 2.0 Authorization Code 예제
• 카카오 로그인 OAuth 구현 방법
• Access Token Refresh Token 차이점