OAuth 2.0 동작 원리: 소셜 로그인 구현 전 알아야 할 4가지 역할과 Grant Type

📌 핵심 요약

  • OAuth 2.0은 "비밀번호를 공유하지 않고 권한만 위임"하는 프로토콜입니다.
  • 참여자 4대장: Resource Owner, Client, Authorization Server, Resource Server
  • 보안의 핵심: 프론트엔드가 아닌 백엔드에서 토큰을 교환하는 Authorization Code Grant 방식 상세 분석

과거에는 내 앱이 사용자의 구글 주소록을 가져오려면, 사용자에게 "구글 ID랑 비밀번호 좀 알려줘"라고 요구했습니다. 보안상 미친 짓이죠. 내 앱이 해킹당하면 사용자의 구글 계정도 털리기 때문입니다.

이 문제를 해결하기 위해 등장한 것이 OAuth (Open Authorization)입니다. 쉽게 말해 "호텔 발렛파킹 키"와 같습니다. 발렛 직원(내 앱)에게 내 차(데이터)를 맡길 때, 마스터키(비밀번호)가 아닌 시동과 문 열기만 가능한 발렛 전용 키(Access Token)를 주는 것입니다.

OAuth 2.0 권한 코드 흐름

1. OAuth 2.0의 4가지 역할 (Roles)

문서를 읽을 때 이 용어들이 헷갈리면 이해가 불가능합니다. 딱 정리해 드립니다.

용어 설명 예시
Resource Owner 정보 주인 (사용자) 로그인하려는 사람
Client 정보를 쓰고 싶은 앱 우리가 개발하는 서비스
Authorization Server 인증 담당 서버 구글/카카오 로그인 서버
Resource Server 데이터 저장소 구글/카카오 API 서버

2. 가장 안전한 방식: Authorization Code Grant

OAuth에는 여러 방식이 있지만, 보안상 가장 안전하고 표준으로 쓰이는 방식은 Authorization Code Grant입니다. 핵심은 "중요한 토큰은 브라우저(Front)에 노출하지 않고 서버(Back)끼리만 주고받는다"는 것입니다.

Step 1. "로그인하러 가기" (Client → Auth Server)

사용자가 '구글 로그인' 버튼을 누르면, 우리 앱은 사용자를 구글 로그인 페이지로 이동시킵니다. 이때 client_id, redirect_uri, scope(요청 권한), response_type=code를 파라미터로 보냅니다.

Step 2. "인증 완료 & 코드 발급" (Auth Server → Client)

사용자가 구글에 로그인을 성공하고 "정보 제공에 동의"를 누르면, 구글은 사전에 약속된 redirect_uri로 사용자를 돌려보냅니다. 이때 URL 뒤에 임시 인증 코드(Authorization Code)를 붙여서 보냅니다.
https://myapp.com/callback?code=abc1234...

💡 중요: 이 code는 Access Token이 아닙니다. "토큰으로 바꿀 수 있는 교환권"일 뿐입니다. 해커가 이걸 훔쳐도 client_secret을 모르면 토큰으로 못 바꿉니다.

Step 3. "토큰 교환" (Client Backend ↔ Auth Server)

이제 우리 앱의 백엔드 서버가 나섭니다. 브라우저로부터 받은 code와 서버에 숨겨둔 client_secret을 합쳐서 구글 서버에 직접 요청(Back-channel)을 보냅니다.
"구글아, 아까 받은 코드가 이건데, 내 비밀키랑 같이 줄게. 진짜 토큰 줘."

Step 4. Access Token 발급 완료

구글이 확인 후 유효하다면, 드디어 Access Token(과 Refresh Token)을 우리 서버에 발급해 줍니다. 이제 우리 서버는 이 토큰을 이용해 구글 API에서 사용자 정보를 가져올 수 있습니다.

3. 왜 Implicit Grant는 쓰지 않나요?

과거에는 SPA(Single Page App)에서 백엔드를 거치지 않고 바로 토큰을 받는 Implicit Grant 방식을 쓰기도 했습니다. 하지만 URL 해시(#)에 토큰이 노출되어 보안에 매우 취약합니다.

현재는 SPA에서도 PKCE (Proof Key for Code Exchange)가 적용된 Authorization Code Grant 방식을 사용하는 것이 표준 권장 사항입니다.

4. 결론

OAuth 2.0 구현 시 "Access Token은 절대 브라우저 URL에 노출되면 안 된다"는 원칙만 기억하십시오.

프론트엔드는 Code만 받아오고, 실제 토큰 교환은 백엔드가 수행해야 합니다. 이것이 소셜 로그인의 보안을 지키는 가장 확실한 아키텍처입니다.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기