OAuth 2.0 프로토콜 초안의 섹션 4.2는 인증 서버가 access_token(자원으로 자신을 인증하는 데 사용되는) 인증 및 refresh_token순수하게 새로운 작성을 위해 사용되는를 모두 리턴 할 수 있음을 나타냅니다 access_token.
https://tools.ietf.org/html/rfc6749#section-4.2
왜 둘 다 있습니까? 왜 access_token최후를 유지 refresh_token하고하지 refresh_token않는가?
답변:
새로 고침 토큰의 개념은 액세스 토큰이 수명이 짧기 때문에 손상 될 경우 공격자가이를 악용 할 수있는 창이 제한되어 있다는 것입니다.
공격자가 액세스 토큰을 얻으려면 새로 고침 토큰 외에 클라이언트 ID와 비밀이 필요하기 때문에 새로 고침 토큰은 손상된 경우 쓸모가 없습니다.
그런 말을 한 인증 서버와 리소스 서버 모두에 대한 모든 호출이 SSL을 통해 수행되므로, - 그들은 액세스 / 새로 고침 토큰을 요청할 때 원래의 클라이언트 ID와 비밀을 포함하여 - 나는에 관해서는 확실 얼마나 "더 이상이다 액세스 토큰 오래 지속되는 새로 고침 토큰 및 clientid / secret 조합보다 타협 할 수 없습니다.
이것은 물론 권한 서버와 리소스 서버를 모두 제어하지 않는 구현과 다릅니다.
다음은 새로 고침 토큰 사용에 대한 좋은 스레드입니다. OAuth Archives .
새로 고침 토큰의 보안 목적에 대해 언급 한 위의 인용문 :
토큰 새로 고침 ... 오래 지속되는 access_token 누수 (비보안 리소스 서버, 베타 또는 잘못 코딩 된 리소스 서버 앱의 로그 파일에있는 쿼리 매개 변수, https가 아닌 사이트의 JS SDK 클라이언트의 access_token을 쿠키 등)
Catchdave가 제공 한 토론 링크에는 Dick Hardt가 만든 또 다른 유효한 요점 (원본, 데드 링크) 이 있으며 위에서 언급 한 내용 외에도 여기에서 언급 할 가치가 있다고 생각합니다.
새로 고침 토큰에 대한 나의 기억은 보안과 취소를위한 것입니다. <...>
해지 : 액세스 토큰이 자체 포함 된 경우 새 액세스 토큰을 발급하지 않으면 권한 부여가 취소 될 수 있습니다. 액세스 토큰이 유효한지 확인하기 위해 리소스가 권한 부여 서버를 쿼리 할 필요가 없습니다. 이렇게하면 액세스 토큰 유효성 검사가 단순화되고 여러 권한 부여 서버를 쉽게 확장하고 지원할 수 있습니다. 액세스 토큰이 유효하지만 권한이 취소되는 시간이 있습니다.
실제로 Resource Server와 Authorization Server가 동일한 엔터티이고 사용자와 이들 간의 연결이 (일반적으로) 똑같이 안전한 상황에서는 새로 고침 토큰을 액세스 토큰과 별도로 유지하는 것이 의미가 없습니다.
인용에서 언급했듯이, 새로 고침 토큰의 또 다른 역할은 사용자가 언제든지 (예를 들어 프로필의 웹 인터페이스를 통해) 액세스 토큰을 해지하고 동시에 시스템을 확장 가능하게 유지하는 것입니다 .
일반적으로 토큰은 서버 데이터베이스의 특정 레코드를 가리키는 임의의 식별자이거나 모든 정보를 자체적으로 포함 할 수 있습니다 (예 :이 정보는 MAC 등 으로 서명해야 함 ).
수명이 긴 액세스 토큰이있는 시스템의 작동 방식
서버는 클라이언트가 토큰을 발행하여 사전 정의 된 범위 세트 내에서 사용자의 데이터에 액세스 할 수 있도록합니다. 토큰을 취소 가능하게 유지하려면 "폐지 된"플래그가 설정 또는 설정 해제 된 토큰과 함께 토큰을 데이터베이스에 저장해야 len(users) x len(registered clients) x len(scopes combination)합니다. . 모든 API 요청은 데이터베이스에 도달해야합니다. O (1)을 수행하는 이러한 데이터베이스에 쿼리하는 것은 쉽지 않지만 단일 실패 지점 자체는 시스템의 확장 성과 성능에 부정적인 영향을 줄 수 있습니다.
수명이 긴 새로 고침 토큰과 수명이 짧은 액세스 토큰이있는 시스템의 작동 방식
여기서 우리는 두 개의 키, 즉 데이터베이스에 해당 레코드가있는 임의 새로 고침 토큰과 만료 타임 스탬프 필드를 포함하는 서명 된 자체 포함 액세스 토큰을 발행합니다.
액세스 토큰은 자체 포함되어 있으므로 유효성을 확인하기 위해 데이터베이스를 전혀 치지 않아도됩니다. 토큰을 해독하고 서명과 타임 스탬프를 확인하기 만하면됩니다.
그럼에도 불구하고 여전히 새로 고침 토큰의 데이터베이스를 유지해야하지만이 데이터베이스에 대한 요청 수는 일반적으로 액세스 토큰의 수명에 의해 정의됩니다 (수명이 길수록 액세스 속도가 낮음).
특정 사용자로부터 고객의 액세스 권한을 취소하려면 해당 새로 고침 토큰을 "해지 됨"으로 표시하거나 완전히 제거해야하며 새 액세스 토큰 발급을 중지해야합니다. 새로 고침 토큰이 취소되는 동안 창이 있지만 액세스 토큰은 여전히 유효 할 수 있습니다.
트레이드 오프
새로 고침 토큰은 액세스 토큰 데이터베이스의 SPoF (단일 실패 지점)를 부분적으로 제거하지만 몇 가지 명백한 단점이 있습니다.
창". 이벤트 "사용자가 액세스를 취소합니다"와 "액세스가 취소됩니다"라는 기간이 있습니다.
클라이언트 로직의 복잡성.
새로 고침 토큰 없이
와 새로 고침 토큰
이 답변이 의미가 있고 누군가가 더 신중한 결정을 내리는 데 도움이되기를 바랍니다. 또한 github 및 foursquare를 포함하여 잘 알려진 OAuth2 공급자가 새로 고침 토큰이없는 프로토콜을 채택하고 있다는 점에 주목하고 싶습니다.
위의 모든 큰 응답에도 불구하고, 나는 구매자 보호 및 사기에보고했다 때 이전에 이베이에서 근무 보안 마스터 학생 및 프로그래머로, 별도의 액세스 말할 수있는 토큰 및 새로 고침 토큰이 자사의 최적의 균형 의 사용자 희롱 사이에 자주 이름을 / 암호 입력 및 권한 남용 을 통해 서비스의 잠재적 남용 에 대한 액세스 권한을 취소합니다 .
이와 같은 시나리오를 생각해보십시오. 3600 초의 액세스 토큰 사용자를 발행하고 하루보다 훨씬 오래 토큰을 새로 고칩니다.
사용자는 좋은 사용자이며 집에 있고 웹 사이트 쇼핑 및 iPhone 검색을 시작 / 해제합니다. 그의 IP 주소는 변경되지 않으며 서버의 부하가 매우 적습니다. 분당 3-5 개의 페이지 요청이 있습니다. 액세스 토큰에서 3600 초가 지나면 새로 고침 토큰이있는 새 토큰이 필요합니다. 우리는 서버 측에서 자신의 활동 기록과 IP 주소를 확인하여 그가 인간이고 자신을 행동한다고 생각합니다. 서비스를 계속 사용할 수 있도록 새로운 액세스 토큰을 부여합니다. 사용자는 새로 고침 토큰 자체의 하루 수명에 도달 할 때까지 사용자 이름 / 비밀번호를 다시 입력 할 필요가 없습니다.
사용자는 부주의 한 사용자입니다. 그는 미국 뉴욕에 거주 하며 바이러스 프로그램을 중단했으며 폴란드 의 해커에 의해 해킹당했습니다 . 해커가 액세스 토큰과 새로 고침 토큰을 받으면 사용자를 가장하여 서비스를 사용하려고합니다. 그러나 단시간 액세스 토큰이 만료 된 후 해커가 액세스 토큰을 새로 고치려고 할 때 서버에서 사용자 행동 기록의 IP가 급격히 변경되었음을 알았습니다 (이 사람은 미국에 로그인하여 폴란드에서 액세스를 새로 고칩니다) 단지 3600 년대 이후 ??). 새로 고침 프로세스를 종료하고 새로 고침 토큰 자체를 무효화하고 사용자 이름 / 암호를 다시 입력하라는 메시지가 표시됩니다.
사용자는 악의적 인 사용자입니다. 그는 로봇을 사용하여 1 분마다 API를 1000 번 호출하여 서비스를 남용하려고합니다. 3600 초가 지난 후에도 액세스 토큰을 새로 고치려고 할 때까지 그렇게 할 수 있습니다. 우리는 그의 행동을 발견하고 그가 인간이 아닐 수도 있다고 생각했습니다. 새로 고침 과정을 거부하고 종료 한 후 사용자 이름 / 암호를 다시 입력하도록 요청합니다. 이것은 로봇의 자동 흐름을 방해 할 수 있습니다. 적어도 그를 불편하게 만듭니다.
업무, 사용자 경험 및 도난당한 토큰의 잠재적 위험 사이에서 균형을 잡을 때 새로 고침 토큰이 완벽하게 작동 한 것을 볼 수 있습니다. 서버 측 워치 독은 IP 변경, API 호출 빈도 이상을 검사하여 사용자가 좋은 사용자인지 아닌지를 결정할 수 있습니다.
또 다른 단어는 각 API 호출에 기본 IP 감시견 또는 기타 조치를 구현하여 도난당한 토큰 / 서비스 남용의 피해 통제를 제한하려고 시도 할 수 있다는 것입니다. 그러나 사용자에 대한 레코드를 읽고 써야하므로 비용이 많이 들고 서버 응답 속도가 느려집니다.
이러한 답변 중 어느 것도 리프레쉬 토큰이 존재하는 핵심 이유에 도달하지 못합니다. 분명히 클라이언트 자격 증명을 인증 서버에 보내서 항상 새로운 액세스 토큰 / 새로 고침 토큰 쌍을 얻을 수 있습니다.
따라서 새로 고침 토큰의 유일한 목적은 유선을 통해 인증 서비스로 전송되는 클라이언트 자격 증명의 사용을 제한하는 것입니다. 액세스 토큰의 ttl이 짧을수록 새로운 액세스 토큰을 얻기 위해 클라이언트 자격 증명을 더 자주 사용해야하므로 공격자가 클라이언트 자격 증명을 손상시킬 수있는 기회가 더 많아집니다. 비대칭 암호화를 사용하여 전송합니다). 따라서 단일 사용 갱신 토큰이있는 경우 클라이언트 신임 정보를 손상시키지 않고 액세스 토큰의 ttl을 임의로 작게 만들 수 있습니다.
약간의 혼동을 없애려면 클라이언트 암호 와 사용자 암호 의 역할을 이해해야합니다 .
클라이언트가 있는 응용 프로그램 / 웹 사이트 / 프로그램 / ..., 원하는 서버에 의해 뒷받침 인증 사용자가 타사 인증 서비스를 사용하여. 클라이언트 시크릿은이 클라이언트와 인증 서버 모두에 알려진 (임의의) 문자열입니다. 이 비밀을 사용하여 클라이언트는 인증 토큰으로 자신을 식별하고 액세스 토큰을 요청할 수있는 권한 을받습니다.
초기 액세스 토큰 및 새로 고침 토큰을 얻으려면 다음이 필요합니다.
그러나 새로 고친 액세스 토큰을 얻으려면 클라이언트 가 다음 정보를 사용합니다.
새로 고침 할 때 클라이언트는 클라이언트 암호를 사용하여 액세스 토큰을 새로 고칠 수있는 권한을 부여 받으므로 사용자 ID + 암호 대신 새로 고침 토큰을 사용하여 사용자를 다시 인증 할 수 있습니다 . 이를 통해 사용자는 자신의 암호를 다시 입력하지 않아도됩니다.
또한 클라이언트 ID와 비밀을 알 수 없으므로 새로 고침 토큰을 잃어도 문제가되지 않습니다. 또한 클라이언트 ID와 클라이언트 비밀을 비밀로 유지하는 것이 중요 하다는 것을 보여줍니다 .
이 답변은 Justin Richer의 OAuth 2 표준 본문 이메일 목록을 통해 제공됩니다. 이것은 그의 허가와 함께 게시됩니다.
새로 고침 토큰의 수명은 (AS) 권한 서버에 달려 있습니다. 만료, 취소 등이 가능합니다. 새로 고침 토큰과 액세스 토큰의 차이점은 대상입니다. 새로 고침 토큰은 권한 부여 서버로만 돌아가고, 액세스 토큰은 (RS) 리소스 서버로갑니다.
또한 액세스 토큰을 얻는다고해서 사용자가 로그인 한 것은 아닙니다. 실제로 사용자가 더 이상 존재하지 않을 수도 있습니다. 실제로는 새로 고침 토큰의 의도 된 사용 사례입니다. 액세스 토큰을 새로 고치면 사용자를 대신하여 API에 액세스 할 수 있으며 사용자가 있는지 여부를 알려주지 않습니다.
OpenID Connect는 액세스 토큰의 사용자 정보를 제공 할뿐만 아니라 ID 토큰도 제공합니다. 이것은 AS 또는 RS가 아닌 클라이언트 자체를 대상으로하는 별도의 데이터입니다. OIDC에서는 새로운 ID 토큰을 얻을 수있는 경우 실제로 프로토콜로 "로그인 한"사람 만 고려해야합니다. 새로 고침하는 것만으로는 충분하지 않습니다.
자세한 내용은 http://oauth.net/articles/authentication/을 참조하십시오
클라이언트는 여러 가지 방식으로 손상 될 수 있습니다. 예를 들어 휴대폰을 복제 할 수 있습니다. 액세스 토큰이 만료되었다는 것은 클라이언트가 권한 서버로 다시 인증해야한다는 것을 의미합니다. 재 인증 중에 권한 서버는 다른 특성을 확인할 수 있습니다 (IOW는 적응 형 액세스 관리를 수행함).
새로 고침 토큰을 사용하면 클라이언트 만 다시 인증 할 수 있습니다. 여기서 다시 인증하면 많은 사용자가 원하지 않는 것으로 표시된 대화 상자가 사용자와 대화합니다.
새로 고침 토큰은 기본적으로 일반 웹 사이트가 1 시간 정도 후에 사용자를 정기적으로 다시 인증하도록 선택할 수있는 장소 (예 : 은행 사이트)에 적합합니다. 대부분의 소셜 웹 사이트는 웹 사용자를 다시 인증하지 않기 때문에 현재 많이 사용되지 않으므로 클라이언트를 다시 인증하는 이유는 무엇입니까?
refresh_token이없고 access_token이없는 한 access_token을 지속시키는 이유는 무엇입니까?
다른 사람들이 제공 한 큰 답변 외에도 새로 고침 토큰을 사용하는 이유와 주장과 관련된 또 다른 이유가 있습니다.
각 토큰에는 사용자 이름, 역할 또는 클레임을 만든 공급자의 모든 내용이 포함될 수있는 클레임이 포함됩니다. 토큰을 새로 고치면 이러한 클레임이 업데이트됩니다.
우리가 토큰을 더 자주 새로 고치면 분명히 아이덴티티 서비스에 더 많은 부담을 주지만 더 정확하고 최신의 주장을 얻고 있습니다.
BT의 답변을 더 단순화하려면 : 일반적으로 사용자가 자격 증명을 다시 입력하지 않아도되지만 여전히 새로 고침 토큰을 취소하여 권한을 취소 할 수 있도록하려면 새로 고침 토큰을 사용하십시오.
액세스 토큰을 취소 할 수 없으며 새로 고침 토큰 만 취소하십시오.
이 답변은 두 명의 선임 개발자 (John Brayton 및 David Jennes)의 도움으로 이루어졌습니다.
새로 고침 토큰을 사용하는 주된 이유는 공격 영역을 줄이는 것입니다.
새로 고침 키가 없다고 가정하고이 예제를 살펴 보겠습니다.
건물에는 80 개의 문이 있습니다. 모든 문은 동일한 키로 열립니다. 키는 30 분마다 변경됩니다. 30 분이 끝나면 열쇠를 키 메이커에게주고 새로운 열쇠를 얻어야합니다.
내가 해커이고 키를 얻으면 30 분이 지나면 키 메이커에게 전달하여 새 키를 얻습니다. 키 변경에 관계없이 모든 도어 를 지속적으로 열 수 있습니다 .
질문 : 30 분 동안 키에 대해 몇 개의 해킹 기회가 있었습니까? 나는 당신이 키를 사용할 때마다 80 개의 해킹 기회를 가졌습니다 (네트워크 요청을하고 자신을 식별하기 위해 액세스 토큰을 전달하는 것으로 생각하십시오). 그것은 80 배의 공격 표면입니다.
이제 동일한 예제를 살펴 보지만 이번에는 새로 고침 키가 있다고 가정하겠습니다.
건물에는 80 개의 문이 있습니다. 모든 문은 동일한 키로 열립니다. 키는 30 분마다 변경됩니다. 새 키를 얻으려면 이전 액세스 토큰을 전달할 수 없습니다. 새로 고침 키만 전달해야합니다.
내가 해커이고 키를 얻는 경우 30 분 동안 사용할 수 있지만 30 분이 지나면 키 메이커에게 키를 보내는 것은 가치가 없습니다. 내가 그렇다면, 키 메이커는이 나쁜 새로 고침 토큰이라고 말할 것입니다. 해킹을 확장하려면 택배를 키 메이커에게 해킹해야합니다. 택배에는 고유 한 키가 있습니다 (새로 고침 토큰이라고 생각).
질문 : 30 분 동안 Refresh 키에 대해 몇 개의 해킹 기회가 있었습니까? 80? 아니요. 해킹 기회는 1 회뿐이었습니다. 그 기간 동안 택배는 키 메이커와 통신합니다. 그것은 1 배의 공격 표면입니다. 키에 대해 80 개의 해킹 기회가 있었지만 30 분이 지나도 좋지 않습니다.
서버는 자격 증명 및 (일반적으로) JWT 서명을 기반으로 액세스 토큰을 확인합니다.
액세스 토큰 유출은 좋지 않지만 일단 만료되면 더 이상 공격자에게 유용하지 않습니다. 새로 고침 토큰 유출은 훨씬 더 나쁘지만 아마도 가능성이 적습니다. (새로 고침 토큰 유출 가능성이 액세스 토큰 유출 가능성보다 훨씬 낮은 지 여부는 의문의 여지가 있다고 생각합니다.)
요점은 액세스 토큰이 모든 요청에 추가되는 반면 새로 고침 토큰은 새로 고침 흐름 동안에 만 사용되므로 MITM이 토큰을 볼 가능성이 적다는 것입니다
빈도는 공격자에게 도움이됩니다. Heartbleed 와 같은 SSL의 잠재적 인 보안 결함, 클라이언트의 잠재적 인 보안 결함 및 서버의 잠재적 인 보안 결함은 모두 유출을 가능하게합니다.
또한 권한 부여 서버가 다른 클라이언트 요청을 처리하는 응용 프로그램 서버와 분리 된 경우 해당 응용 프로그램 서버에는 새로 고침 토큰이 표시되지 않습니다. 더 이상 오래 살지 않는 액세스 토큰 만 볼 수 있습니다.
구획화는 보안에 좋습니다.
마지막 으로이 멋진 답변을 참조하십시오
무슨 새로 고침 토큰이 아닙니다?
새로 고침 토큰을 통해 액세스 수준을 업데이트 / 해제하는 기능은 새로 고침 토큰을 사용하도록 선택한 부산물입니다. 그렇지 않으면 독립형 액세스 토큰이 취소되거나 만료 될 때 액세스 수준이 수정되어 사용자가 새 토큰을 얻을 수 있습니다
당신이 access_token마지막을 매우 길게 만들고, 가지고 있지 않다고 가정하면 refresh_token언젠가 해커가 이것을 얻고 access_token모든 보호 자원에 액세스 할 수 있습니다!
당신이한다면 refresh_token는 access_token해커가 당신을 해킹하기 어렵도록 '의 라이브 시간은 짧 access_token은 시간의 짧은 기간이 지나면 무효 때문이다.
Access_token뿐만 아니라 사용하여 다시 검색 할 수 있습니다 refresh_token뿐만 아니라으로 client_id하고 client_secret,하지 않는 해커.
권한 부여 서버는 새로 고침 토큰을 유지합니다. 액세스 토큰은 자체 포함되어 있으므로 리소스 서버는이를 저장하지 않고 확인할 수 있으므로 유효성 검사시 검색 노력을 줄여줍니다. rfc6749 # page-55에서 토론에 빠진 또 다른 점은
"예를 들어, 권한 서버는 모든 액세스 토큰 새로 고침 응답으로 새 새로 고침 토큰이 발행되는 새로 고침 토큰 회전을 사용할 수 있습니다. 이전 새로 고침 토큰은 무효화되지만 권한 서버에 의해 유지됩니다. 새로 고침 토큰이 손상되어 이후에 사용되는 경우 공격자와 합법적 인 클라이언트 중 하나가 무효화 된 새로 고침 토큰을 제공하여 인증 서버에 위반 사실을 알립니다. "
새로 고침 토큰을 사용하는 요점은 공격자가 어떻게 든 새로 고침 토큰, 클라이언트 ID 및 비밀 조합을 얻을 수 있다고 생각합니다. 이후 새로 고침에 대한 모든 요청이 새 액세스 토큰과 새로 고침 토큰을 생성하는 경우 공격자로부터 새 액세스 토큰을 가져 오는 호출을 추적 할 수 있습니다.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
각 사용자가 하나 이상의 역할에 연결되어 있고 각 역할이 하나 이상의 액세스 권한에 연결되어있는 시스템을 생각해 봅시다. 이 정보는 더 나은 API 성능을 위해 캐시 될 수 있습니다. 그러나 사용자 및 역할 구성에 변경 사항이있을 수 있으며 (예 : 새 액세스 권한이 부여되거나 현재 액세스 권한이 취소 될 수 있음) 캐시에 반영되어야합니다.
이러한 목적으로 액세스 및 새로 고침 토큰을 사용할 수 있습니다. 액세스 토큰으로 API를 호출하면 자원 서버는 캐시에 액세스 권한이 있는지 확인합니다. 새로운 액세스 부여가 있으면 즉시 반영되지 않습니다. 액세스 토큰이 만료되고 (예 : 30 분) 클라이언트가 새로 고침 토큰을 사용하여 새 액세스 토큰을 생성하면 DB의 업데이트 된 사용자 액세스 권한 정보로 캐시를 업데이트 할 수 있습니다.
다시 말해, 액세스 토큰을 사용하는 모든 API 호출에서 새로 고침 토큰을 사용하는 액세스 토큰 생성 이벤트로 비싼 작업을 옮길 수 있습니다.
먼저 클라이언트는 권한 부여 권한을 부여하여 권한 부여 서버로 인증합니다.
그런 다음 클라이언트는 액세스 토큰을 제공하여 보호 된 리소스에 대한 리소스 서버를 요청합니다.
리소스 서버는 액세스 토큰의 유효성을 검사하고 보호 된 리소스를 제공합니다.
클라이언트는 액세스 토큰을 부여하여 리소스 서버에 보호 된 리소스 요청을합니다. 여기서 리소스 서버는이를 확인하고 유효한 경우 요청을 처리합니다. 이 단계는 액세스 토큰이 만료 될 때까지 계속 반복됩니다.
액세스 토큰이 만료되면 클라이언트는 권한 부여 서버로 인증하고 새로 고침 토큰을 제공하여 새 액세스 토큰을 요청합니다. 액세스 토큰이 유효하지 않은 경우 자원 서버는 유효하지 않은 토큰 오류 응답을 클라이언트에 다시 보냅니다.
클라이언트는 새로 고침 토큰을 부여하여 권한 부여 서버로 인증합니다.
그런 다음 권한 서버는 클라이언트를 인증하여 새로 고침 토큰의 유효성을 검사하고 유효한 경우 새 액세스 토큰을 발행합니다.
access token + refresh token있습니까?