열한 번째 발걸음한 번의 인증을 여러 서비스에 연결한다

1. hana의 클라이언트는 AS에 초기 인증을 요청하고, 설정된 사전 인증 방식으로 계정의 비밀을 제어한다는 증거를 제시합니다. 비밀번호 기반 방식에서는 키를 얻는 데 비밀번호가 사용될 수 있지만 문서 서버에 비밀번호를 전달하지 않습니다.

2. AS는 TGT와 클라이언트–TGS 세션 키를 제공합니다. TGT의 필요한 내용은 TGS가 열 수 있는 키로 보호되고, 클라이언트가 사용할 세션 키는 클라이언트가 안전하게 얻을 수 있도록 따로 보호됩니다. 사용자가 TGT 자체를 열어야 하는 것은 아닙니다.

3. 클라이언트는 TGT와 세션 키로 만든 새로운 authenticator를 TGS에 보내 docs용 티켓을 요청합니다. TGS는 티켓과 이번 요청 증거를 확인한 뒤, docs의 장기 키로 보호된 서비스 티켓과 클라이언트–docs 세션 키를 돌려줍니다.

4. 클라이언트는 서비스 티켓과 새 authenticator를 docs에 제시합니다. docs는 자기 장기 키로 티켓을 열어 세션 키를 얻고 이번 요청의 증거를 검증합니다. 요구된 상호 인증에서는 서버도 대응하는 응답을 보냅니다.

5. 시간 제한과 재전송 캐시는 과거 티켓·요청의 무분별한 반복 사용을 억제합니다. 기기 시간의 큰 오차는 정상 인증도 실패하게 할 수 있습니다. 티켓이 유효해도 특정 문서를 읽을 권한이 있는지는 docs의 인가 규칙이 판정합니다.

깨달음같은 비밀을 모든 서비스에 입력하는 대신 용도와 수명이 제한된 티켓과 세션 키가 이동합니다. KDC와 서비스 장기 키의 보호가 전체 신뢰를 지탱합니다.

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