우리가 허가 코드 인증 유형 플로우를
이 playground 사이트에서
임의적으로 시험했을 때
인증 서버가 클라이언트 애플리케이션에 보낸
답변에 대한 회신으로 받았던 것은
두 가지 다른 유형의 토큰입니다
하나는 액세스 토큰이고
두번째로는 리프레쉬 토큰입니다
그리고 리프레쉬 토큰의 경우
다음 날짜까지가 유효기간이라는
정보도 담겨있었습니다
여기서 86,400초가 의미하는 바는
24시간 뒤, 즉 하루 뒤에 유효 기간이 끝난다는 것입니다
내 액세스 토큰의 유효기간이 끝나면
클라이언트 애플리케이션은
인증서나 로그인 플로우를 재시작하기 위해서
엔드 유저나 리소스 소유자에게 다시 물을 필요가 없습니다
허가 코드 인증 유형이 있기 때문이죠
대신, 승인 서버로부터 받았던
리프레쉬 토큰을 활용할 수 있습니다
받은 리프레쉬 토큰을 이용하여
인증 서버와 함께
또 다른 인증 유형 플로우를 시작할 수 있습니다
그리고 리프레쉬 토큰이 적절하다면
인증 서버는 새로운 유효 기간을 가진
새로운 액세스 토큰을 부여할 것입니다
이와 더불어
새로운 리프레쉬 토큰도 발급할 것입니다
그것이 이 리프레쉬 토큰의 목적입니다
이해가 되셨길 바랍니다
엔드 유저나 리소스 소유자에게
로그인 과정을 재시작해달라고 반복적으로 묻는 것이 아니라
24시간 뒤에
클라이언트 애플리케이션이
언제든지 이 리프레쉬 토큰을 사용할 수 있는 것입니다
그리고 뒤에서, 인증 서버에게 특정한 액세스 토큰의
유효 기간이 끝났다는 답변을
받게 된다면
내부적으로 인증 서버에게 또 다른 요청을 보내서
리프레쉬 토큰 인증 유형 플로우를 새롭게 만들어낼 수 있습니다
이 리프레쉬 토큰 유형 플로우가 어떻게 작동되는지
이해하려고 해봅시다
리프레쉬 토큰 인증 유형 플로우에서는
엔드 유저가 관련되지 않습니다
왜냐하면 클라이언트 애플리케이션이 특정 액세스 토큰의
유효기간 만료 소식을 접하자마자
엔드 유저가 관련되지 않도록 할 것이기 때문입니다
그저 단순히 처음 로그인 과정이 시작할 때
받았던 리프레쉬 토큰을 활용할 것입니다
그리고 대체로, 이 리프레쉬 토큰들은
유효기간이 존재하지 않을 것입니다
이 리프레쉬 토큰 인증 유형 플로우의
원리를 이해해보도록 합시다
첫 번째 단계에서는
클라이언트 애플리케이션이
"저는 이러한 리소스에 접근하고 싶습니다"라고
리소스 서버로 요청을 보낼 것입니다
이것이 액세스 토큰입니다
특정 액세스 토큰의 유효기간이 만료됐다는 것은 모릅니다
그러나, 액세스 토큰이 만료되었기 때문에
리소스 서버는 'error 403 forbidden'을 보내며
"죄송하지만 액세스 토큰이 만료되었습니다"라고 말할 것입니다
이에 따라, 클라이언트 애플리케이션은 어떻게 할지 아시겠죠?
인증 서버에 새로운 액세스 토큰이 필요하다고
아무개 사용자에게
요청을 보낼 것입니다
이것은 처음 로그인 과정에서 발급을 받았던
리프레쉬 토큰입니다
이 리프레쉬 토큰이 적절하다면
인증 서버는 새로운 액세스 토큰과
리프레쉬 토큰을 부여할 것입니다
그리고 새로운 리프레쉬 토큰은
클라이언트 애플리케이션이 브라우저 속이나 데이터베이스와 같은 곳에
보관했을 것입니다
그 이후에
클라이언트 애플리케이션은 새롭게 받은 액세스 토큰을
사용하여 리소스 서버에게
요청을 할 것입니다
그리고 리소스 서버는
이번에는 액세스 토큰이 정확했기 때문에
클라이언트 애플리케이션에게
적당한 답변을 회신할 것입니다
이것이 리프레쉬 토큰 인증 유형 플로우의 역사입니다
또, 보시다시피 액세스 토큰 기한 만료 시나리오를 인지하고
리프레쉬 토큰 인증 유형을 시작하는 것을
담당하는 것은 모두
뒤에서 클라이언트 애플리케이션이
맡아야 하는 일입니다
절대로 엔드 유저를 연관짓지 않아야 하며
엔드 유저는 뒤에서 어떤 일이 일어나고 있는 듯한
느낌을 받아서는 안됩니다
이 모든 일은 몇 초 안에
비밀스럽게 일어나야 합니다
이제 클라이언트 애플리케이션이 인증 서버에게
리프레쉬 토큰 인증 유형을 시작하려고 할 때마다
보내야 했던 요청 사항을
살펴보도록 합시다
여기서 볼 수 있듯이, 세 번째 단계에서는
클라이언트 애플리케이션이
클라이언트 아이디와 클라이언트 기밀이 무엇인지
인증 서버에게 공유해야 합니다
이후에는
리프레쉬 토큰이 무엇인지 전달해야 하며
처음에 무엇이었는지도 밝혀야 합니다
리프레쉬 토큰 이후에는
스코프 세부 사항을 보내야 하죠
마지막으로 클라이언트 애플리케이션이 보내야 하는
중요한 정보는 인증 유형입니다
이 인증 유형 플로우는
리프레쉬 토큰과 스코프 토큰에 대한
값을 보내야 합니다
따라서 이 값에 따라 승인 서버는
리프레쉬 토큰을 가져가고
새로운 리프레쉬 토큰과 액세스 토큰을 발급해야 할지 결정합니다
왜 액세스 토큰 또한 만료되지 않도록 할 수 없는지에
대해 질문이 있을 수 있겠다는
생각이 듭니다
이 리프레쉬 토큰에 의지할 필요가 없게끔 하자는 말이겠죠?
하지만 이 접근법을 추천하지는 않습니다
그 이유는 액세스 토큰이
만료되지 않는다면
만약 누군가 이 액세스 토큰을 가지게 된다면
그들이 실명과 비밀번호만 알면
어떻게든지 사용할 수 있기 때문입니다
이러한 이유로 대기업에서 제공되는
승인 서버들은
무제한이나 만료기간 없는
액세스 토큰을 부여하지 않습니다
그들은 운영방침에 따라 언제나
24시간 혹은 7일의 기간을 정해놓습니다
이러한 동일한 매커니즘은
리소스 소유자 인증서 유형에도 해당됩니다
로그인 과정에서
액세스 토큰과 리프레쉬 토큰을 받았다면
리소스 소유자 인증서를 계속해서
요구해서는 안됩니다
대신, 클라이언트 애플리케이션은
리프레쉬 토큰을 활용하여
새로운 액세스 토큰을 얻을 수 있습니다
이로써, 우리는 인증코드와 같은 대부분의
인증 유형 플로우와
클라이언트 인증서에 대해 알아보았습니다
장치 코드는 웹 애플리케이션에 적합하지 않습니다
이건 무시하셔도 됩니다
리프레쉬 토큰에 대해 이야기 나누었고
암시적인 플로우에 대해 이야기 나누었고
비밀번호 인증 유형도 다루었습니다
우리가 다루지 않은 플로우는 PKCE 플로우밖에 없습니다
두 번째에 쓰여있는 것이죠
이 PKCE 인증 유형 플로우는
다음 강의에서 다룰 예정인데
EasyBank 웹 애플리케이션에서
OAuth 2 구조물을 실행하는 것에 대해 이야기해보겠습니다
지금으로선 그걸 걱정하지 않아도 됩니다
다음 강의에서 더 자세히 알아볼 수 있기 때문입니다
따라서, 우리가 오늘 다룬 플로우에 대해
매우 확신을 가지고 있으실 것이라고 예상합니다
제가 제공해 드리는 playground 웹사이트를 적극적으로 활용합시다
만약 질문이 있으시다면
playground 웹사이트에서
여러분이 모든 내용을 이해하실 수 있도록
인증 유형 플로우를 언제든지 탐색해보실 수 있습니다
감사하고, 다음 강의에서 뵙겠습니다. 수고하셨습니다