2012-08-28 3 views
2

OAuth2를 사용하는 API로 작업 중이며 3600 초 만에 만료되는 액세스 토큰을 제공하고 새로 고침 토큰을 제공합니다. 원래, 액세스 토큰이 만료되었다는 것을 나타내는 방식으로 API 호출이 실패하기를 기다렸다가 새로 고침 토큰을 사용하여 액세스 토큰을 새로 고치려고했습니다. 이것은 액세스 토큰이 만료되고 여러 API 호출이 동시에 이루어질 때 (각 호출이 개별적으로 새로 고침을 트리거하고 대부분의 호출이 실패 할 때) 문제가됩니다.OAuth2 액세스 토큰 새로 고침을위한 적절한 패러다임

3600 초 후에 새로 고침 토큰을 사용하여 액세스 토큰을 자동으로 새로 고치는 것이 더 좋습니까? (또는 3599 초 또는 3601 초?) 액세스 토큰 새로 고치기에 사용해야하는 다른 패러다임이 있습니까?

답변

1

이상적으로 만 클라이언트는 만료 된 액세스 토큰을 사용하지 않아도되는 충분한 지능을 가져야합니다. 다행히도 OAuth AS의 토큰 엔드 포인트의 응답에는 만료 시간을 3600 초로 확인하기 위해 expires_in 속성이 포함되어야합니다. 이 JSON 응답이 서버에서 생성되기 때문에 예컨대 :

{"token_type":"Bearer","expires_in":3600,"refresh_token":"p8BPdo01kkjh6fhatclD3wwBEQblm4kL4ctYRVlrHo","access_token":"9XebAAXeu6hQOAiwmOk8vdhRyUFV"} 

는 다시 클라이언트로 전송이 시간을 촬영하고있다, 따라서 "expires_in"값이 나타나는 것보다 작을 수있는 기회가있다.

감안할 때 자동으로 새로 고침 토큰을 사용하여 새 액세스 토큰을 요청하려면 만료되기 전에 일종의 버퍼 (예 : 5-10 초)가 있어야합니다.

+0

그래서'(expires_in - 5)'또는'(expires_in - 10)'초 정도 후에 실제로 자동으로 새로 고쳐야합니까? – Isaac

+0

나는 그 접근법을 권장 할 것입니다. 클라이언트는 이미 가지고있는 정보를 고려할 때 확실히 그렇게 할 기회가 있습니다. –

+1

그러나 OP의 여러 동시 요청 시나리오에서 새 토큰이 요청되면 바로 이전 토큰이 무효화되므로이 요청 웨이브 중에 새로 고침이 발생하면 이미 사용 된 요청이 아직 사용되지 않았습니다. 요청 중 하나가 새로 고침되면 이전 토큰이 실패합니다. – Magnus

관련 문제