STEP 1: 권한 부여 요청 (Authorization Request)

내가 쇼핑몰 앱에서 '구글 계정으로 로그인' 버튼을 딱 눌렀어.
그러면 내 브라우저는 구글 로그인 페이지로 이동(리디렉션)하게 돼. 이때 쇼핑몰 앱은 그냥 보내는 게 아니라, URL에 중요한 정보들을 쿼리 파라미터로 담아서 보내.

GET https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=YOUR_CLIENT_ID&
 scope=openid%20profile%20email&
 redirect_uri=https://oauth.my-awesome-app.com/callback

• response_type=code: "인증 코드 그랜트 방식으로 진행할게요! 그러니 나중에 **인증 코드(code)**를 주세요." 라는 뜻.
• client_id: 쇼핑몰 앱이 구글에 미리 등록하고 받은 고유 식별자. "안녕하세요, 저 '재능넷'인데요." 하고 신분증을 보여주는 것과 같아.
• scope: "제가 사용자의 어떤 정보에 접근하고 싶은데요, 허락해주세요." 라고 요청하는 권한의 범위야. 여기서는 '프로필'과 '이메일' 정보를 요청하고 있네.
• redirect_uri: 구글이 인증 절차를 끝내고 사용자를 다시 돌려보낼 쇼핑몰 앱의 주소. 보안을 위해 이 주소는 구글에 미리 등록된 주소와 정확히 일치해야 해.

STEP 2: 사용자 인증 및 동의

이제 내 화면에는 익숙한 구글 로그인 창이 떠. 나는 내 구글 아이디와 비밀번호를 입력해서 로그인해.
로그인이 성공하면 구글은 나에게 물어봐. **"이 '쇼핑몰 앱'이 당신의 프로필과 이메일 정보에 접근하려고 하는데, 허락하시겠습니까?"**

이 화면이 바로 '동의 화면(Consent Screen)'이야. 내가 여기서 '동의' 버튼을 누르는 행위가 바로 리소스 소유자(나)가 클라이언트(쇼핑몰 앱)에게 권한을 위임하는 핵심적인 순간이지.

STEP 3: 인증 코드 발급

내가 '동의'를 누르면, 구글(인증 서버)은 약속대로 내 브라우저를 아까 쇼핑몰 앱이 알려준 redirect_uri로 다시 돌려보내.
이때! URL 뒤에 **'인증 코드(Authorization Code)'**를 붙여서 보내줘. 마치 택배 운송장 번호를 발급해주는 것과 같아.

https://oauth.my-awesome-app.com/callback?code=4/0AY0e-g78...

이 `code`는 수명이 매우 짧고(보통 몇 분 이내) 딱 한 번만 사용할 수 있는 일회성 코드야. 만약 이 코드가 중간에 탈취되더라도, 공격자가 이걸로 바로 내 정보에 접근할 수는 없어. 왜냐하면 다음 단계가 남아있기 때문이지.

STEP 4: Access Token 교환 요청 (백엔드 통신)

자, 이제 쇼핑몰 앱의 **백엔드 서버**가 나설 차례야. 이게 이 방식의 가장 중요한 포인트야.
브라우저(프론트엔드)는 백엔드 서버에게 방금 받은 `code`를 전달해. 그러면 백엔드 서버는 이 `code`와 함께 자신의 비밀 열쇠인 `client_secret`을 포함해서, 구글의 토큰 발급 엔드포인트에 직접 요청을 보내. 이 통신은 사용자의 브라우저를 거치지 않고 서버 대 서버로 은밀하게 이루어져.

POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=4/0AY0e-g78...&
redirect_uri=https://oauth.my-awesome-app.com/callback&
client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET

• grant_type=authorization_code: "저 인증 코드 가져왔으니, 이제 진짜 카드키(Access Token)로 바꿔주세요."
• code: 방금 브라우저를 통해 전달받은 일회성 인증 코드.
• client_secret: 쇼핑몰 앱의 비밀키. 이 비밀키를 알고 있다는 건, 이 요청이 진짜 쇼핑몰 앱의 서버에서 온 것임을 증명하는 강력한 수단이야.

STEP 5: Access Token 발급

구글(인증 서버)은 쇼핑몰 앱이 보낸 `code`, `client_id`, `client_secret` 등이 모두 유효한지 확인해. 모든 게 완벽하다면, 드디어 최종 카드키인 **'Access Token'**과, 필요에 따라 'Refresh Token'을 발급해서 쇼핑몰 앱의 백엔드 서버에게 응답으로 보내줘.

{
  "access_token": "ya29.a0AfH6... (이게 진짜 카드키!)",
  "expires_in": 3599,
  "refresh_token": "1//04G... (카드키 유효기간 만료 시 재발급용)",
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer"
}

이제 쇼핑몰 앱의 백엔드 서버는 이 `access_token`을 안전하게 저장해 둬. (예: 데이터베이스나 세션)

STEP 6: 리소스 접근 (API 호출)

드디어 쇼핑몰 앱은 발급받은 `access_token`을 가지고 구글의 리소스 서버(예: Google People API)에 내 정보를 요청할 수 있게 됐어.
요청을 보낼 때 HTTP 헤더에 이 토큰을 포함시켜서 보내. "저 카드키 가지고 왔으니, 이 사람 프로필 정보 좀 주세요!" 하는 거지.

GET https://people.googleapis.com/v1/people/me?personFields=names,emailAddresses
Authorization: Bearer ya29.a0AfH6...

구글 리소스 서버는 이 토큰이 유효한지 확인하고, 유효하다면 요청받은 내 이름과 이메일 주소를 쇼핑몰 앱에게 전달해줘. 쇼핑몰 앱은 이 정보를 받아서 회원가입을 자동으로 처리하거나, 로그인 상태로 만들어주는 거야. 모든 과정이 끝났어!

STEP 1: 권한 부여 요청

시작은 인증 코드 그랜트와 비슷해. 사용자가 '로그인' 버튼을 누르면, 클라이언트 앱이 인증 서버로 사용자를 리디렉션시켜.
그런데 결정적인 차이가 있어. response_type이 code가 아니라 token이야.

GET https://accounts.google.com/o/oauth2/v2/auth?
 response_type=token&
 client_id=YOUR_CLIENT_ID&
 scope=openid%20profile%20email&
 redirect_uri=https://my-spa-app.com/callback

response_type=token: "안녕하세요! 저 백엔드 없어요. 복잡한 거 말고 그냥 바로 **Access Token**을 주세요." 라는 강력한 의사 표현이야.

STEP 2: 사용자 인증 및 동의

이 단계는 인증 코드 그랜트와 완전히 똑같아. 사용자는 인증 서버(구글, 카카오 등)에 로그인하고, "이 앱이 내 정보에 접근하는 것을 허용할까요?" 라는 물음에 '동의'를 눌러.

STEP 3: Access Token 직접 발급

자, 여기서부터 완전히 달라져.
사용자가 동의하면, 인증 서버는 인증 코드를 주는 대신 **Access Token을 직접 만들어서** redirect_uri로 보내줘.
근데 그냥 보내는 게 아니라, URL의 **프래그먼트(fragment)**, 즉 # 뒤에 붙여서 보내줘.

https://my-spa-app.com/callback#access_token=xyZ123...&token_type=Bearer&expires_in=3600

왜 하필 프래그먼트일까? URL 프래그먼트는 서버로 전송되지 않는다는 특징이 있어. 오직 클라이언트 측의 브라우저만 읽고 처리할 수 있지. 그래서 자바스크립트로 이 값을 파싱해서 토큰을 획득하는 거야.

이러면 끝이야! 백엔드 서버와의 통신 같은 복잡한 과정이 전혀 없지. SPA 앱은 자바스크립트로 URL에서 토큰을 쏙 빼내서 변수에 저장하고, 바로 이 토큰을 이용해서 리소스 서버에 API 요청을 보낼 수 있어.

STEP 1: 사용자 자격증명 수집

클라이언트 앱(예: 공식 트위터 모바일 앱)의 로그인 화면에 사용자가 자신의 트위터 아이디와 비밀번호를 직접 입력해.

STEP 2: Access Token 요청

클라이언트 앱은 사용자가 입력한 아이디(username)와 비밀번호(password)를 받아서, 자신의 client_id, client_secret과 함께 인증 서버의 토큰 엔드포인트로 바로 쏴버려.

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=password&
username=USER_NAME&
password=USER_PASSWORD&
client_id=CLIENT_ID

grant_type=password: "저 사용자한테 직접 아이디랑 비번 받았어요. 이거 맞는지 확인하고 Access Token 주세요." 라는 뜻. 브라우저 리디렉션 같은 거 전혀 없어. 그냥 서버 간의 API 호출 한 방으로 끝나.

STEP 3: Access Token 발급

인증 서버는 전달받은 아이디와 비밀번호가 올바른지 확인해. 맞다면, 바로 Access Token을 발급해서 클라이언트 앱에게 돌려줘.
이제 클라이언트 앱은 이 토큰으로 리소스 서버에 접근할 수 있게 되는 거지.

STEP 1: Access Token 요청

클라이언트(예: 주문 처리 서버)가 인증 서버에 자신의 `client_id`와 `client_secret`을 보내면서 토큰을 요청해. 사용자의 아이디/비번 같은 건 당연히 없어.

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

grant_type=client_credentials: "저 사용자 아니구요, 클라이언트 본인인데요. 제 신분증(ID, Secret) 확인하시고 저한테 권한 좀 주세요." 라는 뜻.

STEP 2: Access Token 발급

인증 서버는 클라이언트의 자격증명이 유효한지 확인하고, 이 클라이언트에게 부여된 권한을 담은 Access Token을 발급해줘.
이제 주문 처리 서버는 이 토큰을 가지고 재고 관리 서버의 API를 안전하게 호출할 수 있게 되는 거야.

STEP 1 (추가): Code Verifier와 Code Challenge 생성

인증을 시작하기 전에, 클라이언트 앱(SPA, 모바일 앱)이 먼저 **임의의 비밀 문자열**을 하나 만들어. 이걸 **`code_verifier`**라고 불러. 이건 정말 나만 아는 비밀이야.

code_verifier = "aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890..." (랜덤하고 긴 문자열)

그 다음, 이 `code_verifier`를 **SHA256 해시 함수**로 암호화하고, **Base64URL 인코딩**을 적용해. 이렇게 변환된 값을 **`code_challenge`**라고 불러. 이건 공개돼도 괜찮은 값이야.

code_challenge = BASE64URL-ENCODE(SHA256(code_verifier))

STEP 2 (변경): 인증 요청 시 Code Challenge 전달

이제 인증 서버로 권한 부여를 요청할 때, 아까 만든 `code_challenge`와 어떤 방식으로 암호화했는지 알려주는 `code_challenge_method`를 파라미터에 추가해서 보내.

GET https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=YOUR_CLIENT_ID&
 ...
 &code_challenge=E9Mel...&
 &code_challenge_method=S256

인증 서버는 이 `code_challenge`를 일단 저장해 둬. 그리고 평소처럼 로그인/동의 절차를 거쳐 클라이언트에게 **인증 코드**를 발급해줘.

STEP 3 (변경): 토큰 요청 시 Code Verifier 전달

클라이언트가 인증 코드를 받아서 토큰을 요청할 차례야. 이때! 토큰 요청 파라미터에 아까 맨 처음에 만들었던, 나만 아는 비밀 문자열 **`code_verifier`**를 추가해서 보내.

POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=4/0AY0e-g78...&
redirect_uri=...&
client_id=YOUR_CLIENT_ID&
code_verifier=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890...

여기엔 `client_secret`이 없다는 걸 주목해!

STEP 4 (추가): 서버에서 검증

인증 서버는 토큰 요청을 받으면, 함께 온 `code_verifier`를 이전에 저장해 뒀던 `code_challenge_method`(S256) 방식으로 똑같이 변환해 봐.
그리고 그 결과가 처음에 받았던 `code_challenge`와 일치하는지 비교하는 거야.

만약 두 값이 일치한다? "아하! 인증 코드를 요청했던 그 클라이언트가 맞구나!"라고 확신하고 안전하게 Access Token을 발급해줘.
만약 일치하지 않는다면? "이놈은 코드를 훔쳐 온 가짜구나!"라고 판단하고 요청을 거부해버리지.

공격자가 중간에 인증 코드를 가로채더라도, 원본 `code_verifier`를 모르기 때문에 절대 토큰을 발급받을 수 없게 되는 거야. 완벽한 방어지!