[실무 웹 인증과 보안 완벽 가이드 #05] 개발자라면 알아야 할 소셜 로그인: OAuth 2.0 핵심 동작 방식 이해하기

안녕하세요! 지난 4편에서는 프론트엔드 개발자들의 영원한 숙제인 '토큰 저장 위치 논쟁'을 완벽하게 정리하며 우리 서비스만의 강력한 자체 로그인 아키텍처를 완성했습니다.

"드디어 로그인 쪽은 끝났다!" 하고 커피를 한 모금 마시려는 찰나, 기획자분이 다가와서 해맑게 웃으며 말합니다. "개발자님~ 요즘 누가 귀찮게 폼에다가 아이디 비번 쳐서 가입해요? 카카오로 1초 만에 시작하기, 구글로 로그인하기 버튼 3개만 뚝딱 달아주세요!"

네, 올 것이 왔습니다. 바야흐로 대 소셜 로그인의 시대입니다. 그런데 카카오 로그인은 도대체 어떻게 구현하는 걸까요? 우리 서버에 유저 비밀번호가 없는데 어떻게 로그인을 시켜주죠? 이 모든 마법의 중심에는 OAuth 2.0 (Open Authorization 2.0) 이라는 위대한 프로토콜이 자리 잡고 있습니다.

오늘, 수많은 주니어 개발자들을 멘붕에 빠뜨리는 OAuth 2.0의 복잡한 통신 흐름을 세상에서 가장 쉽게 박살 내드리겠습니다.

 

1. 비슷한 듯 완전히 다른 두 단어: Authentication vs Authorization

OAuth 2.0을 이해하려면, 개발자들이 밥 먹듯이 헷갈리는 영어 단어 두 개를 먼저 짚고 넘어가야 합니다. 바로 인증(Authentication)과 인가(Authorization)입니다.

• Authentication (인증 - "너 누구야?"): 유저가 자신이 누구인지 증명하는 과정입니다. "제 아이디는 admin이고, 비밀번호는 1234입니다. 저 맞죠?" 하고 신분증을 내미는 행위입니다.
• Authorization (인가 - "너 이거 할 수 있어?"): 신원이 확인된 유저에게 특정 권한을 부여하는 과정입니다. "오, admin 님이시군요. VIP 라운지에 들어가실 수 있는 권한(출입증)을 드릴게요."

재미있는 점은, OAuth 2.0의 이름이 'Open Authorization'이라는 것입니다. 즉, 애초에 이 기술은 로그인을 위해 만들어진 게 아니라, "내 구글 캘린더 일정 좀 대신 읽어와 줄래?" 하고 권한(인가)을 위임하기 위해 만들어진 기술입니다. 하지만 이 권한을 주는 과정 자체가 너무 안전하고 확실하다 보니, 전 세계 개발자들이 "어? 이거 그냥 로그인(인증)용으로 써도 기가 막히겠는데?" 하고 가져다 쓰게 된 것이죠. (이를 명확히 구분하기 위해 OIDC라는 개념도 있지만, 오늘은 생략하겠습니다!)

 

 

2. OAuth 2.0 연극의 4대 등장인물 (용어 정리)

OAuth 공식 문서를 열면 듣도 보도 못한 용어들이 쏟아져 나와 창을 닫게 만듭니다. 딱 4명의 등장인물만 기억하세요! (카카오 로그인을 예시로 들겠습니다.)

1. Resource Owner (자원 소유자 = 바로 여러분, 유저): 카카오톡 계정을 가지고 있고, 자신의 프로필 사진이나 이메일(자원)의 진짜 주인입니다.
2. Client (클라이언트 = 우리가 만든 서비스): 카카오 입장에서 볼 때, 유저의 정보를 달라고 떼쓰는 손님(Client)입니다. 프론트엔드와 백엔드를 모두 합친 우리 서비스를 의미합니다.
3. Authorization Server (권한 서버 = 카카오 로그인 화면): 유저에게 아이디와 비밀번호를 입력받아 카카오 유저가 맞는지 확인하고, 권한을 증명하는 '토큰'을 발급해 주는 카카오의 문지기 서버입니다.
4. Resource Server (자원 서버 = 카카오 API 서버): 유저의 진짜 데이터(프로필 이름, 이메일, 친구 목록 등)를 금고에 보관하고 있는 카카오의 데이터 서버입니다. 문지기(Authorization Server)가 발급해 준 토큰을 가져와야만 데이터를 내어줍니다.

 

 

3. 가장 헷갈리는 통신 흐름: Authorization Code Grant 완벽 해부

자, 이제 배우들이 무대에 올랐습니다. OAuth 2.0에는 여러 가지 통신 방식이 있지만, 보안이 가장 강력하여 실무에서 99% 사용되는 'Authorization Code Grant (권한 부여 코드 승인 방식)'의 흐름을 따라가 보겠습니다. 프론트, 백엔드, 카카오 서버가 탁구공을 주고받듯 춤추는 과정을 잘 따라오세요!

[1막: 유저의 허락 구하기]

1. 유저(Resource Owner)가 우리 서비스(Client) 화면에서 [카카오로 1초 만에 시작하기] 버튼을 누릅니다.
2. 프론트엔드는 유저의 브라우저를 카카오 로그인 페이지(Authorization Server)로 확 이동(Redirect)시켜버립니다.
3. 유저는 카카오 화면에서 💛노란색 폼에 자신의 카카오 아이디와 비밀번호를 치고 로그인합니다.
4. 카카오는 유저에게 묻습니다. "이 낯선 서비스가 당신의 이메일과 프로필 사진을 가져가려는데, 허락하시겠습니까?" 유저가 [동의하고 계속하기]를 누릅니다.

[2막: 임시 티켓(Authorization Code)의 등장] 5. 유저가 동의하는 순간, 카카오는 유저의 브라우저를 다시 우리 서비스로 돌려보냅니다. 이때 URL 뒤에 꼬리표 하나를 달아줍니다. 특정 url이 code 값이 바로 '인가 코드(Authorization Code)'라는 임시 교환권입니다. 프론트엔드는 얼른 이 코드를 복사해서 우리 서버(백엔드)로 던져줍니다.

[3막: 백엔드와 카카오의 은밀한 거래 (토큰 교환)] 7. 코드를 넘겨받은 백엔드 개발자는 바빠집니다. 이 코드는 수명이 매우 짧은 임시 티켓입니다. 백엔드는 카카오 서버(Authorization Server)로 은밀하게 뒷단 통신을 보냅니다. "카카오야, 방금 유저가 허락해서 받은 임시 코드(1a2b3c4d) 여기 있어! 그리고 우리가 누군지 증명하는 Client ID랑 Secret Key도 같이 줄게. 이제 진짜 토큰(Access Token)으로 교환해 줘!" 8. 카카오 서버는 코드와 비밀키가 모두 일치하는지 꼼꼼히 확인한 후, 비로소 카카오 전용 Access Token을 우리 백엔드 서버로 발급해 줍니다.

[4막: 드디어 유저 정보 획득 및 우리 서비스 로그인 처리!] 9. 백엔드는 방금 받은 카카오 Access Token을 들고 이번엔 카카오 API 서버(Resource Server)로 쳐들어갑니다. "문 열어! 토큰 가져왔어! 아까 그 유저 이메일이랑 프로필 사진 내놔!" 10. 카카오 API 서버는 토큰을 확인하고 유저 정보를 백엔드에 넘겨줍니다. 11. 백엔드는 받아온 이메일(예: test@kakao.com)을 확인합니다. 우리 서비스 DB에 이미 가입된 이메일이라면? 바로 '우리 서비스 전용 자체 JWT 토큰(Access/Refresh)'을 뚝딱 만들어서 프론트엔드로 내려줍니다. (만약 처음 보는 이메일이라면, 회원가입 로직을 태운 뒤 토큰을 줍니다.) 12. 프론트엔드는 4편에서 배운 대로 토큰을 안전하게 저장하고, 유저에게 "로그인 성공!" 화면을 띄워줍니다.

 

 

4. 왜 이렇게 복잡하게 할까? (핵심 면접 질문)

"아니, 그냥 5번 단계에서 카카오가 프론트엔드한테 바로 Access Token을 줘버리면 안 되나요? 왜 굳이 임시 '인가 코드(Code)'를 한 번 거쳐서 백엔드가 다시 교환하게 만들죠?"

아주 날카로운 질문입니다! 면접관들이 정말 좋아하는 질문이기도 하죠. 그 이유는 바로 프론트엔드(브라우저)를 믿을 수 없기 때문입니다.

만약 카카오가 프론트엔드 URL로 진짜 Access Token을 바로 꽂아준다면, 해커가 중간에서 URL을 가로채거나 브라우저 방문 기록을 훔쳐서 토큰을 빼앗아 갈 위험이 매우 큽니다. (Implicit Grant 방식이라고 하는데, 현재는 보안상 쓰지 말라고 권고됩니다.)

그래서 탈취당해도 금방 만료되는 '임시 인가 코드'만 프론트엔드에 던져주고, 진짜 중요한 토큰 교환은 해커가 절대 볼 수 없는 서버와 서버(백엔드 ↔ 카카오) 간의 은밀하고 안전한 통신을 통해서만 이루어지도록 철저하게 설계한 것입니다. 이것이 바로 OAuth 2.0이 그토록 견고하고 훌륭한 프로토콜로 칭송받는 이유입니다.

 

마치며: 완벽한 기능 뒤에 숨어있는 그림자

오늘은 소셜 로그인의 근간이 되는 OAuth 2.0의 개념과 가장 중요한 Authorization Code Grant 통신 흐름에 대해 깊숙하게 알아보았습니다. 프론트엔드가 인가 코드를 따오고, 백엔드가 그걸 진짜 토큰과 유저 정보로 바꿔오는 이 환상적인 티키타카만 이해하셨다면, 구글이든 네이버든 애플 로그인이든 어떤 소셜 로그인도 두렵지 않으실 겁니다.

자, 이제 우리 서비스는 강력한 자체 로그인과 편리한 소셜 로그인까지 모두 갖추었습니다. 그런데 말입니다. 우리가 4편에서 토큰 저장 위치를 고민할 때 잠깐 등장해서 우리를 벌벌 떨게 했던 이름, 기억하시나요?

"게시판에 이상한 스크립트를 올렸더니 유저들 지갑이 다 털렸어!"

다음 [6편] 프론트엔드 보안의 적: XSS와 CSRF 공격 원리와 완벽한 방어 기술 편에서는, 프론트엔드 개발자라면 무조건 알아야 할 양대 해킹 공격 기술과 이를 막아내는 브라우저 보안의 세계로 떠나보겠습니다. 심호흡 단단히 하시고, 6편에서 만나요!

 

[실무 웹 인증과 보안 완벽 가이드 #06] XSS와 CSRF 공격 원리와 완벽한 방어 기술작성 포인트