구글이 액세스 토큰에 관해 설명한다 :에 설명 된대로 완벽한 보안을 위해, 또한 id_token와 access_token과를합니다 (id_token가 제출 한 'at_hash'로 access_token과의 잘린 해시를 포함) 교차 검증합니다.
OAuth 2.0과 관련하여 인증에 사용되는 경우 혼란스러운 대리 문제는 Implicit Grant protocol flow에 적용됩니다. Google이 "클라이언트 측 응용 프로그램 용 OAuth 2.0"을 호출하는 것은 암시 적 승인 프로토콜 흐름을 기반으로합니다.
암시 적 플로우는 URI 조각을 통해 최종 사용자에게 액세스 토큰을 노출하므로 액세스 토큰이 변조 될 가능성이 있습니다. 합법적 인 앱 (OAuth 클라이언트)은 다른 (악의적 인) 앱으로 발행 된 액세스 토큰을 수락하여 혼란스러운 대리인이되어 공격자가 피해자의 계정에 액세스 할 수있게합니다.
액세스 토큰의 유효성을 검사하는 중요한 단계는 액세스 토큰이 다른 앱에 처음 발행되지 않았 음을 앱이 확인하는 것입니다. Google calls attention to this when they say :
참고 : 토큰을 검증 할 때, 그것은 정확히 CLIENT_ID은 API 콘솔에 등록 일치하는 응답 관객 필드를 확인하는 것이 중요합니다. 이것은 혼란스러운 대리 문제에 대한 완화이며,이 단계를 수행하는 것은 절대적으로 중요합니다.
단순한 예로, (1) 파일 저장소, 합법적 인 파일 저장소 앱 및 (2) EvilApp가 있습니다. 두 앱 모두 클라이언트 측 앱용 Google의 인증 프로세스를 사용합니다. Alice는 무고한 최종 사용자이고 그녀의 Google 사용자 ID는 XYZ입니다.
- 앨리스는 Google을 사용하여 FileStore에 로그인합니다.
- 인증 프로세스가 끝난 후 FileStore는 Alice에 대한 계정을 생성하고이를 Google 사용자 ID XYZ와 연결합니다.
- 앨리스는 일부 파일을 자신의 FileStore 계정에 업로드합니다. 지금까지 모든 것이 좋습니다.
- 나중에 Alice가 EvilApp에 로그인하여 재미있는 게임을 제공합니다.
- 결과적으로 EvilApp는 Google 사용자 ID XYZ와 연결된 액세스 토큰을 얻습니다.
- EvilApp의 소유자는 이제 FileStore의 리디렉션 URI를 구성하여 Alice의 Google 계정에 발급 된 액세스 토큰을 삽입 할 수 있습니다.
- 공격자가 FileStore에 연결합니다. FileStore는 액세스 토큰을 가져다가 Google에서 어떤 사용자인지 확인합니다. Google은 사용자 XYZ라고 말합니다.
- FileStore는 공격자가 Google 사용자 XYZ의 액세스 토큰을 가지고 있기 때문에 공격자가 Alice의 파일에 액세스 할 수있게합니다.
FileStore의 실수는 Google에 FileTalk에 제공된 액세스 토큰이 실제로 발급되었다는 것을 확인하지 않고있었습니다. 토큰은 실제로 EvilApp에 발행되었습니다.
다른 사람들은 내가보다 훨씬 더 우아하게이 설명했습니다 :
그게 합리적이라고 생각합니다. 여기에 대한 나의 이해가있다. Google 서버는 토큰이 발행 된 사용자를 확인할 수 있으므로 해당 부분은 정상적으로 작동한다. 그러나 클라이언트는 (토큰 유효성 검사없이) 토큰이 발급 된 클라이언트를 확인할 수 없습니다. 즉, 혼란스러워하는 클라이언트입니다. 그 맞습니까? – Jakob
맞습니다. –
은 매우 간단한 용어로 설명됩니다. 감사. 모두가 그러한 사례를 제공하기를 바랍니다! – arajashe