인증 코드 하나가 로그인으로 바뀌는 과정

1. 앱은 이번 시도의 상태값과 예측하기 어려운 비밀 검증값인 code_verifier를 만듭니다. 검증값은 보관하고, 이를 SHA-256 기반의 S256 방식으로 변환한 code_challenge를 인증 요청에 담습니다. 등록된 redirect URI와 필요한 scope, 변환 방식 S256도 함께 보냅니다. OIDC 요청에 nonce를 사용했다면 이후 ID 토큰에서도 같은 값을 확인합니다.

2. 인증기관이 사용자를 인증하고 필요한 동의를 얻으면 짧게 유효한 인증 코드를 정해진 callback으로 보냅니다. 앱은 요청과 응답의 연결을 확인하고, 받은 코드와 보관한 code_verifier로 토큰을 요청합니다. 인증기관은 이 값을 같은 S256 방식으로 변환해 해당 코드에 연결된 code_challenge와 대조합니다. 일치해야 교환을 계속하므로, 코드를 가로챈 것만으로는 비밀 검증값을 모르는 주체가 토큰을 받을 수 없습니다.

3. 앱은 ID 토큰의 서명, issuer, 자신을 가리키는 audience, 유효 시각과 적용되는 nonce 조건을 검증합니다. 주체 sub는 발급자와 함께 계정에 연결합니다. 이메일 표시 문자열만 전역적으로 같은 사용자라고 가정하지 않습니다.

4. API는 access token의 수신 대상과 권한 범위를 확인합니다. 토큰 형식이 JWT일 수도 있지만 OAuth가 모든 access token을 JWT로 요구하는 것은 아닙니다. 토큰을 해독해 읽었다는 사실은 서명·정책 검증을 마쳤다는 뜻이 아닙니다.

깨달음SSO는 증거를 다른 서비스가 신뢰할 수 있게 전달하는 설계입니다. 어떤 토큰을 누구에게 보여 주는지까지 이해해야 실제 로그인이 완성됩니다.