Cyber Security Academy · 강의

OAuth 2.0 흐름

권한 부여와 토큰을 알아봅니다.

OAuth 2.0 흐름은(는) CoddyKit의 무료 Cyber Security Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Cyber Security Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Cyber Security Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

OAuth 2.0이 실제로 해결하는 문제

OAuth 2.0은 위임된 권한 부여 프레임워크입니다. 사용자가 비밀번호를 공유하지 않고도 타사 애플리케이션에 다른 서비스의 리소스에 대한 제한된 접근 권한을 부여할 수 있게 합니다.

이는 사용자가 누구인지 확인하는 인증이 아니라 앱이 무엇을 할 수 있는지 정하는 권한 부여에 관한 것입니다.
앱은 범위가 지정된 access_token을 받으며, 사용자의 자격 증명은 받지 않습니다.

방어 담당자는 다음을 기억해야 합니다. OAuth만으로는 신원을 증명할 수 없습니다. 액세스 토큰을 로그인 증명으로 취급하는 것은 OIDC가 해결하는 고전적인 실수입니다.

네 가지 역할

모든 OAuth 흐름에는 네 가지 역할이 포함됩니다. 위협 모델링을 위해 이 역할을 정확히 매핑하는 것이 중요합니다.

자원 소유자 데이터를 소유한 사용자입니다.
클라이언트 접근을 요청하는 앱입니다.
권한 부여 서버(AS) 동의 후 토큰을 발급합니다.
자원 서버(RS) 보호된 데이터를 보유한 API이며 토큰을 검증합니다.

이 역할들 사이에는 신뢰 경계가 존재합니다. 침해된 클라이언트나 권한을 과도하게 허용하는 AS는 전체 연결 고리를 약화시킵니다.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

권한 부여 코드 승인

권한 부여 코드 승인은 웹 및 모바일 앱에 권장되는 흐름입니다. 사용자를 대상으로 하는 리디렉션과 비밀 토큰 교환을 분리합니다.

사용자를 AS로 리디렉션하여 인증과 동의를 진행합니다.
AS는 등록된 리디렉션 URI로 수명이 짧은 code를 반환합니다.
클라이언트는 별도 통신 경로를 통해 서버 측에서 코드를 토큰으로 교환합니다.

토큰을 별도 통신 경로에서 얻기 때문에 브라우저의 주소 표시줄이나 방문 기록에 토큰이 나타나지 않습니다.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: 권한 부여 코드 교환을 위한 증명 키

PKCE(RFC 7636)는 권한 부여 코드 승인을 강화하며, 이제 기밀 클라이언트를 포함한 모든 클라이언트에 권장됩니다.

클라이언트는 임의의 code_verifier를 생성하고 그 해시를 code_challenge로 보냅니다.
토큰을 교환할 때 원래 검증자 값을 제시해야 합니다.

이를 통해 코드가 원래 요청자에게 연결되므로, 권한 부여 코드를 가로챈 공격자가 이를 사용하지 못하게 됩니다.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

클라이언트 자격 증명 승인

클라이언트 자격 증명 승인은 사용자가 관여하지 않는 시스템 간 접근을 위한 것입니다(예: 백엔드 서비스가 API를 호출하는 경우).

클라이언트는 자체 자격 증명으로 인증하고 액세스 토큰을 받습니다.
사용자 동의는 없으며 일반적으로 갱신 토큰도 없습니다.

이 토큰의 범위를 엄격하게 제한하고 클라이언트 비밀값을 교체하십시오. 최종 사용자를 사칭하기 위해 이 흐름을 사용하지 마십시오.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

액세스 토큰과 갱신 토큰 비교

OAuth는 유효 기간과 취급 규칙이 매우 다른 두 가지 주요 토큰 유형을 발급합니다.

액세스 토큰 수명이 짧으며 모든 호출에서 자원 서버로 전송됩니다. 소지자 자격 증명으로 취급하십시오.
갱신 토큰 수명이 길며 새 액세스 토큰을 얻기 위해 AS에만 사용됩니다.

갱신 토큰은 가치가 높습니다. 안전하게 저장하고 클라이언트에 연결하며 철회를 지원하십시오.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

베어러 토큰과 전송

대부분의 OAuth 액세스 토큰은 베어러 토큰입니다. 현금을 가진 사람이 사용할 수 있는 것처럼, 토큰을 가진 사람은 누구나 사용할 수 있습니다.

항상 TLS를 통해 전송하고, 로그와 리퍼러로 유출될 수 있는 URL에는 절대 포함하지 마십시오.
Authorization 헤더를 통해 보내십시오.
위험도가 높은 API에는 송신자 제한 토큰(DPoP, mTLS)을 고려하십시오.

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

암시적 권한 부여는 더 이상 사용되지 않음

기존의 암시적 권한 부여는 리디렉션 URI 프래그먼트에 토큰을 직접 반환했습니다. 이제 OAuth 2.0 보안 BCP에서는 권장하지 않으며, OAuth 2.1에서는 제거되었습니다.

토큰이 브라우저 방문 기록, 리퍼러 헤더, 로그를 통해 유출되었습니다.
백 채널이 없어서 클라이언트 인증이 더 취약했습니다.

대신 SPA에는 PKCE를 적용한 권한 부여 코드 흐름을 사용하십시오.

state 매개변수와 CSRF

state 매개변수는 리디렉션 단계에서 CSRF를 방어합니다. 클라이언트가 무작위 값을 생성하고 세션에 저장한 후 콜백에서 검증합니다.

반환된 state가 일치하지 않으면 응답을 거부하십시오.
이렇게 하면 공격자가 피해자 세션에 자신의 권한 부여 코드를 주입하는 것을 막을 수 있습니다.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

범위와 최소 권한

범위는 토큰이 부여하는 액세스 권한의 세분화 수준을 나타냅니다. 모든 단계에 최소 권한 원칙을 적용하십시오.

기능에 필요한 범위만 요청하십시오(admin이 아닌 read:profile).
리소스 서버는 유효한 토큰을 신뢰하는 데 그치지 말고 각 엔드포인트에서 범위를 적용해야 합니다.

지나치게 광범위한 동의는 현실에서 흔히 발생하는 위험입니다. 사용자가 필요한 수준보다 훨씬 많은 권한을 요청하는 앱을 승인하기 때문입니다.

흔한 OAuth 잘못된 구성

대부분의 OAuth 사고는 프로토콜 자체가 아니라 구성에서 비롯됩니다.

오픈 리디렉션 / 느슨한 리디렉션 URI 일치를 허용하면 공격자가 코드를 탈취할 수 있습니다.
state 또는 PKCE가 없으면 CSRF와 코드 주입이 가능해집니다.
해지 기능 없이 수명이 긴 액세스 토큰을 사용하는 경우
액세스 토큰을 인증 어설션으로 취급하는 경우

정확한 리디렉션 URI를 등록하고 엄격하게 검증하십시오.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

빠른 확인: SPA 인증 보안 설정

아래 시나리오에 맞는 올바른 최신 흐름을 선택하십시오.

요약: OAuth 2.0 흐름

핵심 요점:

OAuth 2.0은 인증이 아니라 위임된 권한 부여입니다.
네 가지 역할은 리소스 소유자, 클라이언트, 권한 부여 서버, 리소스 서버입니다.
권한 부여 코드 + PKCE가 웹, 모바일, SPA의 기본 방식입니다.
클라이언트 자격 증명은 머신 간 액세스를 처리합니다.
state, 엄격한 리디렉션 URI 일치 검사, 수명이 짧은 액세스 토큰, 모든 구간의 TLS로 보호하십시오.
암시적 권한 부여와 비밀번호 권한 부여는 더 이상 사용되지 않습니다.

자주 묻는 질문

“OAuth 2.0 흐름” 강의는 무료인가요?

네 — “OAuth 2.0 흐름” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Cyber Security Academy 강의 전체를 잠금 해제할 수 있습니다. Cyber Security Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“OAuth 2.0 흐름”에서 뭘 배우나요?

권한 부여와 토큰을 알아봅니다. 브라우저에서 직접 실행하는 실습 코드로 Cyber Security Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Cyber Security Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Cyber Security Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“OAuth 2.0 흐름” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Cyber Security Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Cyber Security Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Cyber Security Academy(으)로 돌아가기