Google API 및 OAuth2 작업을 시작했습니다. 클라이언트가 내 앱을 승인하면 "새로 고침 토큰"과 짧은 "액세스 토큰"이 제공됩니다. 이제 액세스 토큰이 만료 될 때마다 새로 고침 토큰을 Google에 게시하면 새 액세스 토큰이 제공됩니다.

내 질문은 액세스 토큰 만료의 목적이 무엇입니까? 새로 고침 토큰 대신 오래 지속되는 액세스 토큰이없는 이유는 무엇입니까?

또한 새로 고침 토큰이 만료됩니까?

Google OAuth2 워크 플로에 대한 자세한 내용은 OAuth 2.0을 사용하여 Google API 에 액세스를 참조하십시오 .

이는 구현에 따라 다르지만 일반적인 아이디어는 공급자가 장기 새로 고침 토큰으로 단기 액세스 토큰을 발급 할 수 있도록하는 것입니다. 왜?

• 많은 공급자가 보안 측면에서 매우 약한 베어러 토큰을 지원합니다. 그것들을 단명하게 만들고 새로 고침을 요구함으로써 공격자가 도난당한 토큰을 남용 할 수있는 시간을 제한합니다.
• 대규모 배포는 모든 API 호출마다 데이터베이스 조회를 수행하지 않으려는 대신 암호 해독으로 확인할 수있는 자체 인코딩 액세스 토큰을 발급합니다. 그러나 이는 또한 이러한 토큰을 취소 할 수있는 방법이 없어서 짧은 시간 동안 발행되어 새로 고쳐 져야합니다.
• 새로 고침 토큰에는 더 강력한 클라이언트 인증이 필요합니다. 위의 액세스 토큰과 달리 일반적으로 데이터베이스 조회로 구현됩니다.

몇 가지 시나리오는 oauth2 (또는 다른 인증) 시스템을 설계 할 때 액세스 및 새로 고침 토큰의 목적과 엔지니어링 트레이드 오프를 설명하는 데 도움이 될 수 있습니다.

웹앱 시나리오

웹앱 시나리오에는 몇 가지 옵션이 있습니다.

1. 자체 세션 관리가있는 경우 세션 상태 서비스의 세션 상태에있는 세션 ID에 대해 access_token 및 refresh_token을 모두 저장하십시오. 사용자가 리소스에 액세스해야하는 페이지가 요청되면 access_token을 사용하고 access_token이 만료 된 경우 refresh_token을 사용하여 새 페이지를 가져 오십시오.

누군가가 세션을 도용한다고 가정 해 봅시다. 가능한 유일한 것은 페이지를 요청하는 것입니다.

2. 세션 관리가없는 경우 access_token을 쿠키에 넣고이를 세션으로 사용하십시오. 그런 다음 사용자가 웹 서버에서 페이지를 요청할 때마다 access_token을 보내십시오. 필요한 경우 앱 서버가 access_token을 새로 고칠 수 있습니다.

1과 2 비교

1에서 access_token 및 refresh_token은 권한 부여 서버 (귀하의 경우 Google)와 앱 서버 사이의 경로를 통해서만 이동합니다. 이것은 보안 채널에서 수행됩니다. 해커는 세션을 가로 챌 수 있지만 웹 앱과 만 상호 작용할 수 있습니다. 2에서 해커는 access_token을 가져 와서 사용자가 액세스 권한을 부여한 리소스에 대한 자체 요청을 구성 할 수 있습니다. 해커가 access_token을 보유하더라도 리소스에 액세스 할 수있는 짧은 창만 있습니다.

refresh_token 및 clientid / secret은 서버에만 알려 지므로 웹 브라우저에서 장기간 액세스 할 수 없습니다.

oauth2를 구현하고 액세스 토큰에 시간 초과를 설정했다고 가정 해 봅시다.

1) 짧은 액세스 토큰과 긴 액세스 토큰은 앱 서버에 숨겨져 있기 때문에 큰 차이가 없습니다. 2) 누군가는 브라우저에서 access_token을 가져 와서 오랫동안 사용자의 리소스에 직접 액세스 할 수 있습니다.

모바일 시나리오

모바일에는 내가 아는 몇 가지 시나리오가 있습니다.

1. 장치에 clientid / secret을 저장하고 장치가 사용자의 리소스에 액세스하도록 조정합니다.

2. 백엔드 앱 서버를 사용하여 clientid / secret을 보유하고 오케스트레이션을 수행하십시오. access_token을 일종의 세션 키로 사용하여 클라이언트와 앱 서버간에 전달하십시오.

1과 2 비교

1) 장치에 clientid / secret이 있으면 더 이상 비밀이 아닙니다. 물론 사용자의 허가를 받아 누구나 디 컴파일 한 다음 자신처럼 행동 할 수 있습니다. access_token 및 refresh_token도 메모리에 있으며 손상된 장치에서 액세스 할 수 있습니다. 즉, 사용자가 자격 증명을 제공하지 않고도 앱으로 작동 할 수 있습니다. 이 시나리오에서는 refresh_token이 access_token과 같은 위치에 있기 때문에 access_token의 길이는 해킹 가능성에 영향을 미치지 않습니다. 2) clientid / secret 또는 refresh 토큰이 손상되었습니다. 여기서 access_token 만기 시간은 해커가 사용자 리소스를 얼마나 오래 액세스 할 수 있는지를 결정합니다.

만료 길이

여기서는 access_token 만기 시간이 얼마나되는지에 대해 인증 시스템으로 무엇을 보호하고 있는지에 달려 있습니다. 사용자에게 특히 가치가 있으면 짧아야합니다. 덜 가치있는 것, 더 길 수 있습니다.

Google과 같은 일부 사람들은 refresh_token을 만료하지 않습니다. stackflow와 같은 것들이 있습니다. 만료에 대한 결정은 사용자 편의와 보안 간의 절충입니다. 새로 고침 토큰의 길이는 사용자 반환 길이와 관련이 있습니다. 즉, 새로 고침을 사용자가 앱으로 얼마나 자주 반환하는지 설정합니다. 새로 고침 토큰이 만료되지 않으면 명시 적으로 취소하는 것입니다. 일반적으로 로그온은 취소되지 않습니다.

오히려 길이 게시물이 유용하기를 바랍니다.

다른 응답 외에도 :

일단 액세스 토큰은 일반적으로 클라이언트의 모든 요청과 함께 보호 된 리소스 서버로 전송됩니다. 이는 액세스 토큰 도용 및 재생의 위험을 유발합니다 (물론 액세스 토큰이 "베어러"유형 인 경우 (초기 RFC6750에 정의되어 있음).

실생활에서 이러한 위험의 예 :

• 리소스 서버는 일반적으로 분산 응용 프로그램 서버이며 일반적으로 권한 부여 서버에 비해 보안 수준이 낮습니다 (SSL / TLS 구성이 낮거나 강화 수준이 낮음 등). 반면에 권한 부여 서버는 일반적으로 중요한 보안 인프라로 간주되며보다 심각한 보안 강화가 적용됩니다.

• 액세스 토큰은 리소스 서버 또는 클라이언트에서 진단 목적으로 합법적으로 수집 된 HTTP 추적, 로그 등에 나타날 수 있습니다. 이러한 추적은 공공 또는 준 공공 장소 (버그 추적기, 서비스 데스크 등)를 통해 교환 할 수 있습니다.

• 백엔드 RS ​​애플리케이션은 다소 신뢰할 수있는 타사에 아웃소싱 할 수 있습니다.

반면, 새로 고침 토큰은 일반적으로 유선을 통해 두 번만 전송되며 항상 클라이언트와 권한 부여 서버간에 전송됩니다 . 한 번은 클라이언트가 획득 한 경우 한 번, 새로 고치는 동안 클라이언트가 사용하는 경우 한 번 (이전 새로 고침의 "만료") 토큰). 이것은 인터셉트와 재생을위한 극도로 제한된 기회입니다.

마지막으로 Refresh 토큰은 손상된 클라이언트에 대한 보호 기능이 거의 없습니다.

본질적으로 보안 조치입니다. 앱이 손상된 경우 공격자는 수명이 짧은 액세스 토큰에만 액세스 할 수 있으며 새로운 토큰을 생성 할 방법이 없습니다.

새로 고침 토큰도 만료되지만 액세스 토큰보다 수명이 훨씬 길어야합니다.