OAuth2 흐름

 

 

 

OAuth 2.0(OAuth 2.0)은 한 줄로 말하면:

"비밀번호를 직접 주지 않고,
다른 서비스의 권한을 위임하는 방식"

 

이다.

---

가장 쉬운 예시

"Google로 로그인"

 

생각하면 된다.

---

핵심 아이디어

네 서비스가:

사용자 Google 비밀번호

 

를 직접 알 필요가 없다.

대신:

Google이 인증 완료 후
Access Token 발급

 

해준다.

---

OAuth 등장 전 문제

예전에는 외부 앱이:

사용자 ID/PW 직접 받는 방식

 

많았다.

엄청 위험했다.

---

OAuth는 해결

비밀번호 대신
권한 토큰(Token)

 

을 사용.

---

핵심 구성요소

역할	의미
Resource Owner	사용자
Client	네 서비스
Authorization Server	Google/Kakao
Resource Server	사용자 정보 API

 

---

가장 중요한 흐름

실무에서 제일 많이 쓰는 건:

Authorization Code Flow

 

이다.

---

전체 흐름 먼저

1. 로그인 버튼 클릭
2. Google 로그인 페이지 이동
3. 사용자 로그인/동의
4. Authorization Code 발급
5. 서버가 Access Token 교환
6. 사용자 정보 조회
7. 자체 로그인 처리

 

---

STEP 1 — 로그인 버튼 클릭

사용자:

Google 로그인

 

클릭.

---

STEP 2 — Google 로그인 페이지 이동

브라우저 Redirect.

예:

accounts.google.com

 

---

여기서 중요한 점

비밀번호 입력은 Google에서만

 

한다.

네 서비스는 절대 비밀번호 못 봄.

---

STEP 3 — 사용자 동의

Google이 물어봄:

"이 앱이 이메일 조회해도 됩니까?"

 

---

Scope란?

허용 권한.

예:

Scope	의미
email	이메일 조회
profile	프로필 조회

---

STEP 4 — Authorization Code 발급

로그인 성공 시:

임시 코드(code)

 

를 네 서버로 Redirect.

---

중요한 점

이 코드는:

짧은 시간만 유효

 

하다.

---

STEP 5 — 서버가 Token 교환

이제 네 Backend가 Google 서버에 요청.

Authorization Code
+
Client Secret

 

전송.

---

그러면 Google이

Access Token
Refresh Token

 

발급.

---

왜 서버에서 교환하냐?

Client Secret 보호 때문.

즉:

브라우저에 Secret 노출 금지

 

---

STEP 6 — 사용자 정보 조회

Access Token 사용.

예:

 

Authorization: Bearer ACCESS_TOKEN

 

---

Google API 호출

"이 토큰 사용자 정보 주세요"

 

---

STEP 7 — 자체 로그인 처리

네 서비스는:

Google 사용자 식별

 

후:

• 회원가입
• Session 생성
• JWT 발급

등 수행.

---

Access Token이란?

권한 증명 토큰

 

이다.

즉:

"이 사용자는 이메일 조회 허용함"

 

의 증표.

---

Refresh Token은?

Access Token 만료 시:

새 Access Token 재발급

 

용도.

---

OAuth ≠ 로그인 자체

엄청 중요.

OAuth는 원래:

인가(Authorization)

 

프레임워크다.

---

즉 원래 목적

"권한 위임"

 

이다.

---

로그인은 사실 OpenID Connect

실무에서 "소셜 로그인"은 보통:

• OAuth2
• OIDC(OpenID Connect)

조합.

---

OIDC 추가 기능

사용자 인증(identity)

 

정보 제공.

예:

• email
• sub
• profile

---

OAuth2에서 중요한 보안 포인트

1. redirect_uri 검증

잘못하면 토큰 탈취 가능.

2. state 값 검증

CSRF 방지.

3. Access Token 짧게

보통:

1시간 이하

 

4. HTTPS 필수

토큰 탈취 방지.

---

실무에서 가장 많이 쓰는 구조

Frontend
↓
OAuth Provider(Google)
↓
Backend
↓
JWT/Session 발급

 

---

Spring Security 실무

많이 사용하는 것:

• Spring Security OAuth2 Client
• OAuth2Login

---

흐름 핵심

Spring이:

• Redirect
• state
• token 교환

자동 처리.

---

핵심 한 줄

OAuth2 흐름은:

사용자가 직접 외부 인증 서버(Google 등)에서 로그인하고,
서비스는 비밀번호 대신 Access Token을 받아
권한과 사용자 정보를 위임받는 구조

 

이다.