우리는 수많은 웹사이트와 앱을 이용하면서 ‘로그인’이라는 과정을 무심코 지나칩니다. 하지만 이 간단한 과정 뒤에는 중요한 개념들이 숨어 있습니다. 바로 인증(Authentication)과 인가(Authorization)이죠. 이 글에서는 인증이란 무엇인지, 어떤 방식으로 작동하는지, 왜 중요한지에 대해 깊이 있게 알아보려 합니다.
학습 목표
- 인증(Authentication)과 인가(Authorization)의 차이를 명확히 이해한다.
- 세션 기반과 토큰 기반 인증의 차이점을 설명할 수 있다.
- OAuth 2.0 기반 소셜 로그인의 구조를 이해하고 설명할 수 있다.
- 실제 인증 시스템 구성 흐름을 파악한다.
핵심 키워드
목차 내용
사전 지식
이 학습을 시작하기 전에 다음 개념들에 대한 기본적인 이해가 필요합니다:
HTTP 요청과 응답
웹 브라우저가 서버와 어떻게 통신하는지 이해하면 인증 구조를 더 쉽게 파악할 수 있습니다.
브라우저 저장소
로컬 스토리지, 세션 스토리지, 쿠키의 차이점과 사용법을 알고 있어야 JWT 저장 방식에 대한 이해가 가능합니다.
1. 인증이란 무엇인가요?
"로그인"은 시작일 뿐
사용자가 웹사이트에 접속해 [로그인]을 클릭하고 ID/PW를 입력하는 순간, '인증'이라는 절차가 시작됩니다. 인증(Authentication)이란 사용자의 신원을 확인하는 과정입니다. 서버는 이 과정을 통해 "이 사람이 누구인가?"를 판단합니다.
인증 vs 인가
인증이 "이 사람은 누구인가?"를 확인하는 과정이라면, 인가(Authorization)는 "이 사람이 무엇을 할 수 있는가?"를 결정하는 절차입니다. 인증이 선행되어야 인가가 작동합니다.
한 걸음 더!
실무에서는 인증과 인가를 혼용해서 사용하는 경우도 많습니다. 하지만 이 둘을 명확히 구분하고 이해하는 것이 보안 설계의 첫걸음입니다.
2. 세션 기반 인증과 JWT 방식의 차이
같은 인증, 다른 방식
웹 서비스에서 인증은 두 가지 방식으로 구현될 수 있습니다. 바로 '세션 기반 인증'과 '토큰 기반 인증(JWT)'입니다. 각각의 방식은 데이터 저장 위치와 상태 관리 방식에서 차이가 발생합니다.
| 항목 | 세션 기반 인증 | JWT 기반 인증 |
|---|---|---|
| 저장 위치 | 서버 메모리 | 사용자 브라우저 (쿠키 또는 로컬 스토리지) |
| 상태 관리 | Stateful | Stateless |
| 서버 부하 | 사용자 수 증가 시 증가 | 변화 없음 |
| 확장성 | 낮음 | 높음 (분산 시스템에 유리) |
"JWT 기반 인증은 서버 측 세션 관리를 줄이고 확장성을 높이는 데 탁월한 방식이다."
— _Amazon Web Services_, 2023
AWS 공식 블로그에서도 밝힌 것처럼, JWT는 서버 상태를 기억하지 않기 때문에, 서버를 수평 확장하는 클라우드 환경에 특히 적합합니다.
3. OAuth 2.0 소셜 로그인 이해하기
Google로 로그인, 그 원리는?
"Google 계정으로 로그인", "Kakao 로그인" 등은 모두 OAuth 2.0이라는 프로토콜을 따릅니다. 사용자는 ID/PW를 입력하지 않고, 기존 소셜 계정을 통해 인증을 위임합니다.
- 보안성: 우리 서버는 사용자 비밀번호를 직접 다루지 않기 때문에 보안 위협이 줄어듭니다.
- 사용자 경험: 빠르고 편리한 로그인 경험을 제공합니다.
- 호환성: 다양한 인증 제공자(Google, Facebook, Kakao 등)와 쉽게 연동됩니다.
4. JWT 기반 인증 흐름 자세히 보기
"디지털 신분증"이란?
JWT(JSON Web Token)는 서버가 사용자에게 발급하는 디지털 신분증입니다. 이 토큰은 사용자가 인증에 성공했다는 정보를 담고 있으며, 추후 요청마다 이를 서버에 제출해 신원을 증명할 수 있습니다.
- 로그인 요청: 사용자가 ID/PW를 입력하여 서버에 인증을 요청합니다.
- 토큰 생성: 서버는 사용자 정보를 바탕으로 JWT를 생성하고 서명합니다.
- JWT 전달: 생성된 JWT를 사용자에게 응답으로 전달합니다.
- 보관: 사용자는 이 JWT를 브라우저에 저장해 둡니다. (로컬스토리지/쿠키 등)
- API 요청 시 첨부: 사용자 요청 시 JWT를 Authorization 헤더에 포함시킵니다.
- 서버 검증: 서버는 JWT 서명과 만료 여부를 검증하고 유효 시 요청을 처리합니다.
6. Google API 키 발급 실습
OAuth 키, 이렇게 발급하세요
Google 소셜 로그인은 사용자에게 매우 편리한 인증 옵션입니다. 이를 구현하기 위해 Google Cloud Platform(GCP)에서 우리 애플리케이션을 등록하고 통신에 필요한 '열쇠'를 받아와야 합니다. 아래 절차를 따라 해보세요.
단계 01 웹 브라우저를 열고 [Google Cloud Console](https://console.cloud.google.com/)에 접속합니다. Google 계정으로 로그인하고, 사용할 프로젝트를 선택하거나 새 프로젝트를 생성합니다. 적당한 프로젝트 이름을 넣고 [만들기]를 클릭하여 프로젝트 생성을 완료합니다.
단계 02 왼쪽 탐색 메뉴에서 [API 및 서비스] 섹션을 찾아 [사용자 인증 정보] 메뉴로 이동합니다. 그리고 상단의 [+ 사용자 인증 정보 만들기] 버튼을 클릭하고 드롭다운 메뉴에서 'OAuth 클라이언트 ID'를 선택합니다.
단계 03 프로젝트를 처음 생성을 하면 [동의 화면 구성] 버튼을 만날 수 있습니다. 클릭하면,
- “Google 인증 플랫폼이 아직 구성되지 않았다”는 메시지와 함께 [시작하기] 버튼이 보입니다.
- 마지막으로 프로젝트 구성 화면의 4단계에 필요한 정보를 입력하고 [만들기]를 클릭하여 마무리합니다.
단계 04 OAuth 클라이언트 ID 만들기 화면으로 전환됩니다.
- 애플리케이션 유형: '웹 애플리케이션'을 선택합니다.
- 이름: 이 클라이언트 ID의 용도를 알 수 있도록 이름을 지정합니다. (예: AI Chatbot App Auth)
- 승인된 자바스크립트 원본 - Optional: 일반적으로 비워두거나 필요시 애플리케이션의 기본 URL(예: http://localhost:3000)을 추가할 수 있습니다.
- 승인된 리디렉션 URI 추가 - 중요!: 여기가 가장 중요합니다. Google 로그인이 성공적으로 완료된 후 사용자를 다시 우리 애플리케이션으로 돌려보낼 정확한 주소를 Google에 알려줘야 합니다. 인증 API(예: NextAuth)의 기본 콜백 URL 형식에 맞춰 다음 두 주소를 반드시 추가합니다. (여러 개 추가 가능)
- http://localhost:3000/api/auth/callback/google (로컬 개발 환경용)
- https://여러분의-배포-도메인.com/api/auth/callback/google (나중에 챗봇을 웹에 배포할 경우 사용할 실제 도메인 주소)
주의: 이 주소는 정확히 일치해야 합니다. 오타나 http/https 불일치 시 오류가 발생합니다. - 만들기 및 키 확인: '만들기' 버튼을 클릭하면 'OAuth 클라이언트가 생성됨' 팝업이 나타나며, '클라이언트 ID' 와 '클라이언트 보안 비밀' 이 표시됩니다. 이 두 값은 매우 중요하므로 즉시 복사하여 안전한 곳(예: 비밀번호 관리자)에 보관하세요. 특히 '클라이언트 보안 비밀'은 팝업을 닫으면 다시 확인할 수 없습니다. (만약 놓쳤다면, 사용자 인증 정보 목록에서 해당 클라이언트 ID를 찾아 삭제하고 다시 만들면 됩니다.)
Q&A
마무리하며
이번 글에서는 인증(Authentication)의 기본 개념부터 다양한 방식(JWT, 세션, OAuth 2.0)에 이르기까지 폭넓게 살펴봤습니다. 인증은 단순히 '로그인'만을 의미하지 않습니다. 사용자의 신원을 정확히 확인하고, 그에 따라 권한을 분배하는 핵심 보안 절차입니다. NextAuth와 Supabase 같은 도구를 통해 우리는 실제 서비스에서 사용할 수 있는 견고한 인증 시스템을 손쉽게 구현할 수 있습니다.
함께 읽으면 좋은 글
* 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
'Cook Dev' 카테고리의 다른 글
| 프로젝트 성공의 첫걸음, POC(개념 증명)의 모든 것 (0) | 2025.05.18 |
|---|