OAuth에 토큰 유형이 다른 이유

Question 1

왜 이렇게 다양한 코드와 토큰이 필요한가요? 수명이 90일인 인증 코드를 제공하고 완료하면 어떨까요?

인증 코드는 액세스 토큰을 전달하는 여러 방법 중 하나입니다. 이는 별도의 "단계"가 아니지만 여전히 초기 "대화형 인증" 흐름의 일부입니다. 코드를 사용하려면 OAuth2 클라이언트 비밀(또는 처음에 생성된 PKCE 챌린지)도 필요하다는 점에서 실제 액세스 토큰과 다릅니다. 이론적으로 이는 코드 자체가 가로채더라도(예: 클라이언트 측에 표시되는 리디렉션을 통해) 원래 앱에서만 이를 실제 토큰으로 교환할 수 있음을 의미합니다.

이를 사용하지 않는 다른 흐름도 있습니다. 예를 들어 "암시적 승인" 흐름을 사용하여 액세스 토큰을 직접 받을 수도 있고, OAuth에 따라 인증서를 사용하여 한 단계로 토큰을 인증하고 받을 수도 있습니다. IDP가 지원합니다.

(예를 들어 Google의 "서비스 계정"은 액세스 토큰을 얻기 위해 RSA 키 쌍을 사용하여 인증합니다. 이는 대화형 인증 흐름을 사용하지 않으므로 인증 코드가 없습니다.)

새로 고침 토큰이 만료되면 체인의 시작 부분으로 바로 돌아가서 사용자에게 다시 액세스를 요청해야 한다고 가정하는 것이 맞습니까?

예, 하지만 이를 방지하는 것이 실제로 새로 고침 토큰의 목적입니다.

한 가지 유형의 토큰(액세스 토큰)만 있는 경우 만료될 때마다 체인의 시작 부분으로 바로 돌아가야 합니다. 이는 일반적으로 다음이 있는 새로 고침 토큰을 사용하여 방지할 수 있습니다.더 길게예를 들어 액세스 토큰이 몇 시간 또는 며칠 동안 유효한 경우 새로 고침 토큰은 몇 달 또는 몇 년 동안 유효한 것이 일반적입니다.

새로 고침 토큰의 90일은 비정상적으로 짧으며 토큰을 보유하는 요점이 다소 무색하다고 말하고 싶습니다. 제 생각에는 Azure OAuth2가 훔치기 어려운 자격 증명을 통해 재인증을 강제하기 위해 특별히 그런 방식으로 설정된 것 같습니다. 장치 인증서 또는 사용자 정의 HMAC 구성표 "Windows Hello"로 사용됩니다. (반면에 Google에서 발행한 새로 고침 토큰에는 만료 시간이 전혀 없는 것 같습니다. 저는 수년간 Gmail IMAP에 액세스하는 데 동일한 토큰을 사용해 왔습니다.)

Answer