학습 본문으로 건너뛰기
VAIRODE
HTTP API와 자동화19번째 작은 수업
오늘은 질문 하나만 해결해요19 / 68

처음이어도 괜찮아요 · 그림부터 시작해요

OAuth role·flow와 PKCE 경계를 설명한다

오늘의 질문

resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다. authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.를 방치하면 자동화가 빠르게 반복될수록 잘못된 효과와 비노출 사고도 함께 확대됩니다.

아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.

01 · 가볍게 시작하기

정답을 보기 전에 먼저 골라볼까요?

눈으로만 보고 답 하나를 떠올려 보세요desktop·CLI client가 사용자를 대신해 API 권한을 얻는 흐름의 축소된 local fake server에서 OAuth role·flow와 PKCE 경계를 설명한다 계약을 검토한다.aa19 synthetic request/response script · fixed clock · fake credential sentinel · outbound network disabled
  1. 1
    먼저 골라보기

    틀려도 괜찮아요. 지금 생각한 답 하나를 정해요.

  2. 2
    그림으로 확인하기

    움직이는 순서와 달라지는 곳만 천천히 찾아요.

  3. 3
    내 말로 다시 말하기

    한 문장으로 말해 보면 내가 이해한 곳을 확인할 수 있어요.

02 · 그림으로 보기

그림이 움직이는 순서를 직접 확인해요

OAuth role·flow와 PKCE 경계를 설명한다의 관찰·추론·검증 지도OAuth role·flow와 PKCE 경계를 설명한다의 request 계획, local response, policy 결정, durable effect와 redacted receipt를 번호와 선 종류로 구분한 도식01관찰4개 핵심 용어02추론3개 작동 규칙03검증3개 통과 기준상호작용 SVG 설계안 · OAuth role·flow와 PKCE 경계를 설명한다의 request·response·attempt·effect·checkpoint 경계를 한 화면에서 비교한다.결과가 기준을 통과하지 못하면 관찰로 돌아가 최소 반례를 다시 수집합니다.
  1. 01관찰OAuth role · authorization code · PKCE · refresh token
  2. 02추론resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다. authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.가 발생하면 HTTP 수신 성공과 업무 성공을 분리하고 재시도·중단·격리·사람 개입 중 하나를 정책으로 결정한다. role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt는 raw credential·private URL·개인 데이터 없이도 동일 결정을 재현할 만큼 충분해야 한다.
  3. 03검증OAuth role·flow와 PKCE 경계를 설명한다의 request·response·effect 계약과 terminal/retryable/unknown-effect 분기를 실행 전에 표로 고정한다. authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.를 live API나 실제 credential 없이 재현하고 최초 policy divergence를 국소화한다. role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt로 정상·경계·실패·replay 결과와 비노출을 함께 입증한다.
OAuth role·flow와 PKCE 경계를 설명한다의 request·response·attempt·effect·checkpoint 경계를 한 화면에서 비교한다.resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다.과 authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.를 정상·경계·실패·replay 사건으로 연결하고 role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt를 표시한다.현재 화면: 정적 요약 지도 · 상호작용 설계 범위: synthetic 사건과 단계를 선택하면 request·response·effect·checkpoint·evidence 상태가 동기화된다. · 모션 축소 설계: 자동 이동 없이 선택 상태를 즉시 표시하고 번호·문자 label·선 종류·도형으로 색상 외 의미를 중복 제공한다.

처음 보는 말도 책 읽듯 풀어봐요

이 수업은 쉬운 뜻과 생활 예를 아직 함께 준비하지 못했어요. 설명 없는 정확한 이름은 먼저 보여 주지 않을게요.

그림에서 찾을 쉬운 규칙

  1. 01resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다.
  2. 02authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.가 발생하면 HTTP 수신 성공과 업무 성공을 분리하고 재시도·중단·격리·사람 개입 중 하나를 정책으로 결정한다.
  3. 03role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt는 raw credential·private URL·개인 데이터 없이도 동일 결정을 재현할 만큼 충분해야 한다.

03 · 같이 풀어보기

한 단계씩 따라가면 어렵지 않아요

desktop·CLI client가 사용자를 대신해 API 권한을 얻는 흐름의 축소된 local fake server에서 OAuth role·flow와 PKCE 경계를 설명한다 계약을 검토한다.

함께 볼 작은 예시aa19 synthetic request/response script · fixed clock · fake credential sentinel · outbound network disabled
내 말로 8자 이상 적어요 · 0 / 240

04 · 이제 내가 해볼 차례

여기까지 오면 이런 일을 할 수 있어요

resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다.을 설명하고 실제 인증 없이 synthetic authorization sequence와 PKCE verifier/challenge 검증기를 구현한다.을 local synthetic 환경에서 실행해 role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt로 검증한다.

  • OAuth role·flow와 PKCE 경계를 설명한다의 request·response·effect 계약과 terminal/retryable/unknown-effect 분기를 실행 전에 표로 고정한다.
  • authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.를 live API나 실제 credential 없이 재현하고 최초 policy divergence를 국소화한다.
  • role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt로 정상·경계·실패·replay 결과와 비노출을 함께 입증한다.

05 · 자주 헷갈리는 지점

틀린 답도 이유를 알면 다음에는 맞힐 수 있어요

01OAuth role·flow와 PKCE 경계를 설명한다에서는 2xx 또는 예외 없음만 확인하면 계약 전체가 검증된다.

한 번 더 생각해 볼 질문aa19 synthetic exchange에서 transport 성공이지만 계약이 깨지는 반례와 판정 신호를 쓰세요.

이렇게 고쳐 생각해요resource owner·client·authorization server·resource server 역할을 분리하고 public client의 authorization code flow에는 PKCE를 적용하며 implicit·password식 축약을 새 설계의 기본으로 삼지 않는다.

02authorization code·access token·refresh token을 같은 값처럼 다루거나 verifier를 재사용·노출해 code interception 방어를 무력화한다.가 생기면 같은 요청을 제한 없이 반복하는 것이 가장 안전하다.

한 번 더 생각해 볼 질문aa19 실패를 retryable·terminal·unknown-effect 중 하나로 분류하고 다음 행동을 쓰세요.

이렇게 고쳐 생각해요재시도 가능성·deadline·attempt budget·효과 중복 가능성을 먼저 판정하고 허용된 경우에만 bounded recovery를 수행한다.

03role/endpoint sequence·state/nonce/code-challenge presence·token-value-free flow receipt 대신 raw request·token·response body 전체를 저장해야만 디버깅할 수 있다.

한 번 더 생각해 볼 질문aa19 증거에서 제거할 값과 유지할 결정 신호를 각각 세 개 적으세요.

이렇게 고쳐 생각해요allowlist field·hash·length·status·attempt·synthetic identifier로 증거를 최소화하고 민감 값은 수집 전에 제거한다.

06 · 더 궁금할 때만 보기

선생님과 검토자를 위한 믿을 만한 원문

원문과 어디까지 참고했는지 펼쳐 보기처음 배우는 동안에는 열지 않아도 괜찮아요.
Python Software Foundation · 공개 문서를 확인했어요secrets — Generate secure random numbers for managing secrets

security token 생성, 명시적 entropy 길이와 compare_digest. 일반 simulation jitter에는 별도 deterministic source를 사용한다.

RFC Editor · 공개 문서를 확인했어요Best Current Practice for OAuth 2.0 Security

OAuth security BCP, implicit와 resource owner password grant 경계, authorization code와 PKCE의 현재 보안 방향