프론트와 백엔드의 완벽한 밀당 2탄: OAuth 2.0 소셜 로그인 아키텍처와 백엔드 실무 가이드

프론트와 백엔드의 완벽한 밀당 2탄: OAuth 2.0 소셜 로그인 아키텍처와 백엔드 실무 가이드

이전 글에서 우리는 유저가 아이디와 비밀번호를 직접 입력하는 '자체 로그인' 시스템과 JWT에 대해 깊게 파헤쳐 보았습니다. 그런데 요즘 유저들은 귀찮게 회원가입 폼을 일일이 채우지 않습니다. "카카오로 1초 만에 시작하기", "Google 계정으로 계속하기" 버튼이 없으면 가차 없이 뒤로 가기를 누르고 이탈해 버리죠.

유저 입장에서는 단 1초지만, 그 1초 뒤편에서 프론트엔드와 백엔드, 그리고 카카오(또는 구글) 서버 간에는 엄청나게 치열하고 복잡한 밀당이 일어납니다. 이 우아한 통신 규약이 바로 OAuth 2.0 (Open Authorization 2.0) 프로토콜입니다. 오늘은 수많은 주니어 개발자들이 피눈물을 흘리며 밤을 새우는 OAuth 2.0의 아키텍처와, 실무에서 절대 틀리면 안 되는 백엔드의 핵심 역할을 시원하게 해부해 보겠습니다.

1. OAuth 2.0의 핵심: "내 비밀번호는 주지 않을 테니, 권한만 빌려줄게!" (발레파킹 비유)

OAuth 2.0을 이해할 때 가장 찰떡같은 비유가 바로 '발레파킹(Valet Parking)'입니다.

여러분이 고급 레스토랑에 가서 주차 요원(우리 서비스)에게 차를 맡긴다고 상상해 봅시다. 이때 여러분은 주차 요원에게 차 문을 열고 시동만 걸 수 있는 '발레파킹용 키'를 주지, 집 현관문과 금고까지 다 열 수 있는 '마스터키(구글/카카오 비밀번호)'를 통째로 넘기지 않습니다.

우리 플랫폼(Dev-Match)도 마찬가지입니다. 우리는 유저의 카카오톡 비밀번호를 알 필요도 없고, 알아서도 안 됩니다. 그저 카카오 서버에게 "이 유저가 본인이 맞는지 확인해 주고, 우리 플랫폼에 가입할 수 있도록 이메일 주소랑 프로필 사진만 좀 빼갈 수 있게 열쇠(Access Token) 하나만 발급해 줘!"라고 부탁하는 과정, 그것이 바로 OAuth 2.0입니다.

2. 헷갈리는 등장인물 4인방 완벽 정리

공식 문서를 보면 자꾸 어려운 영어 단어가 나와서 멘붕이 옵니다. 딱 네 명만 기억하세요.

• Resource Owner (자원 소유자): 바로 우리 서비스를 이용하려는 '유저'입니다. 자원(이메일, 프로필 사진)의 주인이죠.
• Client (클라이언트): 카카오에게 자원을 요청하는 '우리 서비스(Dev-Match)'입니다. 프론트엔드와 백엔드를 모두 합친 개념입니다.
• Authorization Server (인가 서버): 유저가 카카오 아이디/비밀번호를 치고 로그인하면, 그것이 맞는지 확인하고 '인가 코드(Authorization Code)'와 '토큰'을 발급해 주는 카카오의 인증 서버입니다.
• Resource Server (자원 서버): 발급받은 토큰을 내밀면, 유저의 진짜 데이터(이메일, 이름)를 꺼내주는 카카오의 API 서버입니다. (보통 인가 서버와 한 몸처럼 움직입니다.)

3. Authorization Code Grant 방식: 실무 표준 흐름 (Step-by-Step)

OAuth 2.0에는 여러 방식이 있지만, 현업 백엔드에서 보안상 무조건 사용하는 방식은 '인가 코드 승인(Authorization Code Grant)' 방식입니다. 흐름을 따라가 볼까요?

1. [프론트엔드 -> 카카오] 로그인 페이지 띄우기: 유저가 '카카오로 로그인' 버튼을 누르면, 프론트엔드는 유저를 카카오의 로그인 화면(https://kauth.kakao.com/...)으로 납치(Redirect)시킵니다.
2. [유저 -> 카카오] 정보 제공 동의: 유저가 노란 화면에서 아이디/비번을 치고 "Dev-Match에 이메일을 제공하는 데 동의하십니까?"에 "동의"를 누릅니다.
3. [카카오 -> 프론트엔드] 인가 코드(Code) 발급: 카카오는 우리 프론트엔드가 미리 설정해 둔 주소(Callback URI)로 유저를 다시 돌려보내면서, URL 뒤에 꼬리표로 인가 코드(Authorization Code)라는 짧은 임시 비밀번호를 달아줍니다. (예: /oauth/callback/kakao?code=a1b2c3d4...)
4. [프론트엔드 -> 백엔드] 코드 전달: 🚨[중요]🚨 프론트엔드는 이 코드를 잡아서 곧바로 우리 백엔드 API로 넘겨줍니다.
5. [백엔드 <-> 카카오] 진짜 토큰 교환 및 유저 정보 획득: 백엔드는 프론트에게 받은 '인가 코드'와, 서버 깊숙이 숨겨둔 '카카오 REST API 키(Secret)'를 들고 카카오 서버의 뒷문으로 몰래 찾아갑니다. 카카오는 이 코드가 유효한지 확인하고 진짜 '카카오 Access Token'을 백엔드에 줍니다. 백엔드는 다시 이 토큰을 들고 카카오 자원 서버(Resource Server)를 찔러서 유저의 '이메일'을 쏙 빼옵니다.

4. 수많은 주니어들이 저지르는 치명적인 보안 실수 (Client-side 토큰 발급)

위 4~5번 과정을 보면 의문이 들 수 있습니다. "아니, 그냥 프론트엔드가 카카오에서 바로 토큰이랑 이메일 다 받아온 다음에, 백엔드한테 '이 사람 홍길동이고 이메일은 이거야, 로그인시켜 줘!'라고 데이터만 띡 던져주면 안 되나요?"

절대, 절대 안 됩니다. 이게 바로 신입 개발자들이 가장 많이 하는 최악의 설계입니다.

만약 프론트엔드가 백엔드에게 "얘 이메일 test@gmail.com 이니까 가입시켜 줘"라고 보낸다고 칩시다. 해커가 중간에 패킷을 가로채서 이메일을 admin@gmail.com(최고 관리자)으로 쓱 조작해서 백엔드로 보내면 어떻게 될까요? 백엔드는 바보같이 "아, 관리자님이 카카오로 오셨군요!" 하고 관리자 권한의 JWT를 내어줍니다. 시스템이 통째로 털리는 겁니다.

그래서 반드시 프론트엔드는 일회용 '인가 코드(Code)'만 백엔드로 넘기고, 백엔드가 직접 카카오 서버와 안전한 서버 대 서버(Server-to-Server) 통신을 통해 유저 데이터를 검증하고 가져와야 합니다. 백엔드가 직접 카카오에게 물어봐서 가져온 이메일만이 100% 신뢰할 수 있는 진짜 데이터이기 때문입니다.

5. FastAPI 실무 코드 아키텍처 (자체 JWT와의 통합)

백엔드가 카카오에서 유저의 이메일을 무사히 가져왔다면, 마지막 단계가 남았습니다. 이 유저를 우리 플랫폼의 식구로 받아들이는 거죠.

# 백엔드의 소셜 로그인(Callback) 처리 논리 구조

def handle_kakao_callback(authorization_code: str):
    # 1. 카카오 서버에 인가 코드를 주고 Access Token을 받아온다.
    kakao_token = fetch_kakao_access_token(authorization_code)
    
    # 2. 받아온 토큰으로 카카오 API를 찔러서 유저 이메일을 가져온다.
    kakao_user_info = fetch_kakao_user_profile(kakao_token)
    email = kakao_user_info.get("email")
    
    # 3. 우리 DB에 이 이메일로 가입한 유저가 있는지 뒤져본다.
    user = db.query(User).filter(User.email == email).first()
    
    if not user:
        # 4-1. 처음 온 유저라면? -> 우리 DB에 회원가입 시킨다! (Auto Sign-up)
        user = create_new_user(email=email, login_type="KAKAO")
        db.add(user)
    
    # 4-2. 이미 가입된 유저라면? -> 이전 글(22번)에서 만든 우리만의 자체 JWT를 발급한다!
    # 카카오 토큰은 버리거나 디비에 처박아두고, 이제부터는 우리 출입증(Access/Refresh Token)을 프론트에게 준다.
    access_token = create_jwt_access_token(user.id)
    refresh_token = create_jwt_refresh_token(user.id)
    
    return {"access_token": access_token, "refresh_token": refresh_token}

이 코드가 이해되시나요? 카카오가 준 토큰은 그저 유저의 신원을 한 번 확인하기 위한 '1회용 신분증 확인' 용도일 뿐입니다. 확인이 끝났으면 우리 플랫폼의 진짜 출입증(자체 JWT)을 발급해서 돌려주는 것, 이것이 소셜 로그인 백엔드 아키텍처의 알파이자 오메가입니다.

6. 마무리

OAuth 2.0은 처음 접하면 등장인물도 많고 흐름도 핑퐁 치듯 복잡해서 머리가 아픕니다. 하지만 "프론트엔드는 코드만 전달하고, 진짜 검증과 자체 JWT 발급은 무조건 백엔드가 한다"는 대원칙 하나만 머릿속에 박아두면 어떤 플랫폼(구글, 네이버, 애플 등)의 로그인 문서라도 술술 읽히기 시작할 겁니다.

가장 어려운 '인증의 벽'을 넘으셨습니다! 다음 글에서는 유저 간의 채팅 시스템, 알림 시스템을 구현하기 위해 단방향 통신인 HTTP를 넘어 양방향으로 실시간 데이터를 쏘아대는 웹소켓(WebSocket) 통신의 세계로 넘어가 보겠습니다.