새로 고침 토큰을 보내는 대신 권한 부여/코드를 다시 보내서 새 액세스 토큰을 얻지 못하는 이유는 무엇입니까?

Question

나는 액세스 토큰이 데이터베이스를 손상시키지 않고 검증되기 때문에 수명이 짧다는 점을 알고 있으며, 새로 고침 토큰은 수명이 길고 데이터베이스에 대해 확인됩니다.

내가 이해할 수없는 것은 처음에는 승인 부여를 보내고 나중에 새로 고침 토큰을 보내 액세스 토큰을받는 것과 다른 점입니다.

이 다이어그램을 RFC 6749에서 보면 클라이언트가 단순히 (G) 단계에서 권한 부여를 다시 보내지 않는 이유는 무엇입니까? 왜 새로 고침 토큰이 필요한가요?

+--------+           +---------------+ 
    |  |--(A)------- Authorization Grant --------->|    | 
    |  |           |    | 
    |  |<-(B)----------- Access Token -------------|    | 
    |  |    & Refresh Token    |    | 
    |  |           |    | 
    |  |       +----------+ |    | 
    |  |--(C)---- Access Token ---->|   | |    | 
    |  |       |   | |    | 
    |  |<-(D)- Protected Resource --| Resource | | Authorization | 
    | Client |       | Server | |  Server | 
    |  |--(E)---- Access Token ---->|   | |    | 
    |  |       |   | |    | 
    |  |<-(F)- Invalid Token Error -|   | |    | 
    |  |       +----------+ |    | 
    |  |           |    | 
    |  |--(G)----------- Refresh Token ----------->|    | 
    |  |           |    | 
    |  |<-(H)----------- Access Token -------------|    | 
    +--------+   & Optional Refresh Token  +---------------+ 

Answer 1

새로 고침 토큰이 초기 코드보다 안전 한 이유가 있다고 생각합니다.

• 코드는 인증 서버에서 리소스 소유자의 브라우저로 전송 된 다음 클라이언트로 전송됩니다. 새로 고침 토큰이 브라우저를 통과하지 않습니다. 따라서 코드는 손상되기 쉽고 단 한 번의 사용으로 수명이 짧아야합니다.
• OAuth 2 specification가 (단지 권장) 클라이언트의 리디렉션 엔드 포인트 보안 전송 계층이 필요하지 않습니다 :이 규격은 때문에이 글을 쓰는 시점에서 TLS의 사용을 강제하지 않는

을 이 필요 클라이언트가 많은 클라이언트 개발자에게 중요한 장애물이됩니다.

하지만

새로 고침 토큰을 얻기를 위해 사용되는 token endpoint, TLS를 필요 : HTTP 요청 ( 일반 텍스트 자격 증명의 전송의 토큰 엔드 포인트 결과에 요청 때문에

및 응답)는 인증 서버는 초기 코드를 불안하게 TLS

의 사용을 요구해야하고 가능한 한 빨리하거나 여러 사용이 detec이다 무효화한다 테드. 토큰을 얻으려면 여전히 클라이언트 비밀이 필요하지만 새로 고침 토큰은 더 안전하며 반복적으로 사용할 수 있습니다.