OAuth

웹 프로젝트를 만들다 보면 로그인 기능을 구현할 때

“카카오 로그인”, “구글 로그인”, “네이버 로그인” 같은 기능을 자주 보게 됩니다.

이때 핵심이 되는 개념이 바로 OAuth 입니다.

 

처음에는 단순히 "소셜 로그인 기술" 정도로 생각하기 쉽지만,

정확히 보면 OAuth는 로그인 자체만을 위한 기술이라기보다 권한 위임을 위한 표준 방식입니다.

쉽게 말해, 사용자가 자신의 비밀번호를 우리 사이트에 직접 입력하지 않아도

외부 서비스가 “이 사용자가 맞다” 혹은 “이 정보 접근을 허용했다”는 것을 전달해 주는 구조입니다.

OAuth 2.0 Login은 스프링 시큐리티에서도 대표적으로 “Login with Google” 같은

로그인 기능 구현에 사용된다고 설명합니다.

 

1. OAuth를 왜 쓰는가

일반 회원가입만 구현하면 사용자는 아이디, 비밀번호를 새로 만들어야 합니다.
하지만 소셜 로그인을 붙이면 사용자는 이미 쓰고 있는 카카오나 구글 계정으로 빠르게 로그인할 수 있습니다.

프로젝트 입장에서도 장점이 있습니다.

첫째, 사용자의 비밀번호를 우리 서비스가 직접 저장하지 않아도 됩니다.
둘째, 회원가입 진입 장벽이 낮아집니다.
셋째, 이메일이나 프로필 같은 기본 정보를 외부 제공자로부터 받아와 회원 생성 흐름을 단순화할 수 있습니다.

즉, OAuth는 사용자 편의성과 보안, 가입 전환율 측면에서 모두 도움이 되는 방식입니다.

2. OAuth와 로그인은 완전히 같은 개념인가

이 부분은 헷갈리기 쉽습니다.

OAuth는 권한 위임입니다.
예를 들어 “이 사용자의 프로필 정보를 읽어도 된다” 같은 허가를 받는 구조입니다. 공식 문서도 OAuth 2.0 자체는 자원 접근을 위한 프레임워크라고 설명합니다.

반면 로그인(인증) 은 “이 사용자가 누구인지 확인하는 것”입니다.
그래서 실제 소셜 로그인에서는 OAuth만 단독으로 보기보다, OpenID Connect 를 함께 보는 경우가 많습니다. OpenID Connect는 OAuth 2.0 위에 인증 계층을 얹어서 사용자 신원을 검증하고 기본 프로필 정보를 표준 방식으로 주고받도록 만든 규격입니다.

정리하면 이렇습니다.

• OAuth: 권한 위임
• 인증(Authentication): 로그인, 신원 확인
• 인가(Authorization): 권한 확인
• OIDC: OAuth 기반 로그인/인증 확장

면접이나 발표에서 이 차이를 구분해서 말하면 훨씬 좋아 보입니다.

3. 내 프로젝트 기준으로 OAuth를 어떻게 이해하면 되는가

사용자 입장에서 흐름은 단순합니다.

1. 사용자가 “카카오 로그인” 버튼을 누릅니다.
2. 카카오 로그인 페이지로 이동합니다.
3. 사용자가 카카오에서 로그인하고 동의합니다.
4. 카카오가 우리 서비스로 다시 돌아오게 합니다.
5. 우리 서버는 전달받은 인가 코드를 바탕으로 토큰을 요청합니다.
6. 토큰으로 사용자 정보를 조회합니다.
7. 우리 서비스 회원 테이블에 이미 존재하는지 확인합니다.
8. 있으면 로그인 처리, 없으면 회원가입 후 로그인 처리합니다.

이 구조에서 중요한 점은 사용자 비밀번호가 우리 DB에 저장되지 않는다는 것입니다.
우리 서비스는 대신 “어느 제공자에서 들어왔는지”, “제공자에서 준 고유 식별자”, “이메일”, “닉네임” 같은 정보를 기반으로 회원을 식별하게 됩니다.

4. OAuth 동작 구조

OAuth에는 몇 가지 역할이 나옵니다.

• Resource Owner: 사용자
• Client: 우리 프로젝트 서버
• Authorization Server: 카카오, 구글 같은 인증 서버
• Resource Server: 사용자 정보를 제공하는 서버 API

OAuth 2.0에서 웹 로그인에 가장 많이 쓰는 방식은 Authorization Code Grant 입니다. 스프링 시큐리티 공식 문서도 OAuth 2.0 Login이 이 Authorization Code Grant를 기반으로 동작한다고 설명합니다.

이 방식을 쓰는 이유는 브라우저에서 바로 민감한 토큰을 다루기보다,
인가 코드를 한 번 거친 뒤 서버가 토큰을 안전하게 교환하도록 만들 수 있기 때문입니다.

5. 프로젝트에서 실제로 저장하면 좋은 정보

소셜 로그인을 붙인 프로젝트라면 회원 테이블이나 별도 연동 테이블에 보통 이런 값들이 필요합니다.

• provider: kakao / google / naver
• provider_user_id: 외부 서비스가 준 고유 사용자 식별값
• email
• nickname
• profile_image
• created_at
• updated_at

예를 들어 같은 이메일이라도 제공자 정책에 따라 값이 다를 수 있어서,
실무적으로는 provider + provider_user_id 조합을 핵심 식별 기준으로 많이 둡니다.

프로젝트를 설명할 때는 이렇게 말하면 좋습니다.

“소셜 로그인 사용자의 비밀번호는 저장하지 않고, 제공자 종류와 제공자에서 전달한 고유 식별값을 기준으로 회원을 식별했습니다.”

이 한 문장만으로도 이해도가 있어 보입니다.

6. 세션 방식과 JWT 방식에서 OAuth는 어떻게 연결되는가

OAuth 로그인 이후 우리 서비스 내부 로그인 상태를 유지하는 방법은 따로 정해야 합니다.

세션 기반

서버가 로그인 상태를 세션에 저장합니다.
JSP/서버 렌더링 프로젝트에서는 이 방식이 비교적 자연스럽습니다.

JWT 기반

로그인 성공 후 우리 서비스가 자체 JWT를 발급해서 클라이언트가 들고 다니게 합니다.

여기서 중요한 건 OAuth 토큰과 우리 서비스 토큰은 다를 수 있다는 점입니다.
카카오에서 받은 액세스 토큰은 카카오 API를 호출할 때 쓰는 것이고,
우리 서비스 로그인 상태 유지에는 별도의 세션이나 JWT를 사용할 수 있습니다.

이 부분을 구분 못 하면 설명이 꼬이기 쉽습니다.

7. Spring Boot / Spring Security에서는 어떻게 붙이는가

스프링 시큐리티는 OAuth2 Login과 OAuth2 Client를 공식 지원합니다.
OAuth 로그인 기능을 쓰려면 spring-security-oauth2-client 관련 지원을 사용하며, 설정에서 provider 정보와 client 정보를 등록하고 oauth2Login() 구성을 적용하는 방식으로 확장할 수 있습니다. 공식 문서에서도 Spring Boot 환경에서 OAuth 2.0 Login 설정과 redirect URI, client 등록 등을 다루고 있습니다.

프로젝트 흐름으로 바꾸면 대략 이런 그림입니다.

• 로그인 버튼 클릭
• /oauth2/authorization/{provider} 로 이동
• 인증 제공자 로그인
• redirect URI로 복귀
• 사용자 정보 조회
• 회원가입 또는 로그인 처리
• 세션 저장 혹은 자체 토큰 발급

즉, 스프링 시큐리티가 중간 인증 흐름을 많이 처리해 주고,
개발자는 사용자 정보 매핑과 회원 연동 로직을 잘 만드는 것이 핵심입니다.

8. 내 프로젝트에서 구현했다고 말할 수 있는 포인트

프로젝트 설명용으로는 아래처럼 정리하면 좋습니다.

1) 사용자 편의성 개선

기존 회원가입 없이도 외부 계정으로 빠르게 로그인할 수 있도록 해
초기 진입 장벽을 낮췄습니다.

2) 보안 부담 감소

비밀번호를 직접 저장하는 구조보다 외부 인증 제공자를 활용해
민감한 인증 정보를 우리 서비스가 직접 다루는 범위를 줄였습니다.

3) 회원 연동 로직 설계

제공자 고유 ID와 이메일 등을 바탕으로
기존 회원 여부를 확인하고 자동 회원가입 또는 로그인 처리 흐름을 구성했습니다.

4) 서비스 내부 인증과 분리

외부 OAuth 로그인 성공 후에는 우리 서비스 기준의 세션 또는 토큰 정책으로
로그인 상태를 유지하도록 설계할 수 있습니다.

이렇게 말하면 “OAuth를 붙였다” 수준이 아니라
왜 필요했고, 어떤 구조로 이해했고, 프로젝트에서 어떤 설계 포인트가 있었는지까지 설명할 수 있습니다.

9. 구현하면서 자주 만나는 문제

OAuth를 붙일 때 자주 생기는 문제도 있습니다.

 

< redirect URI 불일치 >

제공자 설정값과 프로젝트 설정값이 다르면 로그인 후 에러가 납니다.
공식 스프링 문서도 redirect URI 설정을 핵심 단계로 안내합니다.

 

< 제공자별 사용자 정보 구조 차이 >

카카오는 kakao_account, 구글은 다른 형태처럼 응답 JSON 구조가 다를 수 있습니다.
그래서 제공자별 응답을 공통 User DTO로 매핑하는 작업이 필요합니다.

 

< 동일 이메일 중복 처리 >

이메일이 항상 보장되지 않거나 동의 항목에 따라 빠질 수 있습니다.
그래서 이메일만 믿지 않고 provider 고유 ID를 함께 봐야 안전합니다.

 

< 탈퇴/재가입 정책 >

기존에 탈퇴한 회원이 같은 소셜 계정으로 다시 들어오면
재가입으로 볼지, 복구로 볼지 정책이 필요합니다.

 

< 권한 범위(scope) 과다 요청 >

프로필만 필요한데 불필요한 동의를 많이 요청하면
사용자 이탈이 커질 수 있습니다.

10. 보안 관점에서 중요하게 볼 점

OAuth를 붙였다고 해서 자동으로 다 안전한 것은 아닙니다.

• redirect URI를 정확히 제한해야 합니다.
• access token을 프론트에 무분별하게 노출하면 안 됩니다.
• 필요 이상의 scope를 요청하지 않는 것이 좋습니다.
• 로그인 성공 후 우리 서비스 세션 처리도 안전해야 합니다.

스프링 시큐리티는 OAuth2 Login, Client, Resource Server 등 보안 구성을 공식적으로 제공하고 있고, Bearer Token 기반 보호 리소스 접근도 별도 지원합니다.