소셜 로그인 버튼 뒤에서 일어나는 일 — Authorization Code Grant

"GitHub으로 로그인"을 붙이는 건 라이브러리 덕에 10분이면 된다. 그런데 콜백 URL을 왜 등록해야 하는지, code가 뭔지 모르면 장애 때 디버깅이 안 된다. 흐름을 한 번 정리해두자.

등장인물

• 사용자: 브라우저
• 우리 서비스(클라이언트): backtick.blog
• 인증 서버: GitHub

흐름

1. [브라우저 → GitHub]  로그인 버튼 클릭
   github.com/login/oauth/authorize?client_id=...&redirect_uri=...&state=xyz

2. [GitHub]  사용자가 GitHub에 로그인하고 "허용" 클릭

3. [GitHub → 브라우저 → 우리 서버]  콜백으로 리다이렉트
   backtick.blog/api/auth/callback/github?code=abc123&state=xyz

4. [우리 서버 → GitHub]  code + client_secret으로 토큰 교환 (서버 간 통신)
   POST github.com/login/oauth/access_token

5. [우리 서버]  access_token으로 프로필 조회 → 우리 DB의 유저와 연결 → 세션 발급

왜 이렇게 복잡한가

code를 브라우저에 거쳐 보내고, 토큰은 서버 간에만 주고받기 위해서다. access_token이 브라우저 URL에 노출되면 히스토리·로그·리퍼러로 샌다. code는 일회용(수십 초 만료)이고, code만으로는 토큰을 못 받는다 — client_secret이 있어야 하고 그건 서버에만 있다.

state는 CSRF 방지다. 우리가 보낸 값이 그대로 돌아오는지 확인해서, 공격자가 만든 콜백 요청을 걸러낸다.

실무에서 걸리는 것들

• 콜백 URL 불일치: 등록된 redirect_uri와 한 글자만 달라도 거절된다. localhost용/프로덕션용 앱을 따로 만드는 이유
• client_secret 노출: 프론트 코드나 채팅에 올라가면 즉시 재발급(rotate)
• 인증 서버가 주는 access_token과 우리 서비스의 세션은 별개다. 전자는 "그 사람의 GitHub API 열쇠", 후자는 "우리 사이트 로그인 상태"

라이브러리가 다 해주더라도, 4번(서버 간 토큰 교환)이 핵심이라는 것만 기억하면 대부분의 설정 오류를 스스로 풀 수 있다.