OAuth 2 grant flows에 대해
이야기를 나눴던 것을 바탕으로
승인 서버는 항상 액세스 토큰을
클라이언트 애플리케이션에게 발급하는 것에 책임이 있습니다
그리고 동일한 액세스 토큰을 제 클라이언트 애플리케이션이
리소스 서버에게 전송할 수 있습니다
하지만 여기서 생기는 의문은
리소스 서버가 이 액세스 토큰이
적절한지 아닌지를 어떻게 분간하는지입니다
어떻게 승인 서버와
같은 점검을 할 것인가요?
이러한 이유로, 여러가지 접근법이 있습니다
첫 번째 접근법은
승인 서버와 리소스 서버 간
API 교류가 직접적으로 이루어지는 것입니다
제 리소스 서버가 액세스 토큰을 부여받을 때마다
승인 서버에 의해 노출된
API 중 하나를 실행시킬 것입니다
그리고 만약 이 승인 서버가 접근 토큰이 적절하다는 것을
확인하는 데 성공한다면
리소스 서버는 클라이언트 애플리케이션에게
긍정적인 답변을 전송하게 될 것입니다
매우 단순한 접근법입니다
하지만 여기서 볼 수 있듯이
클라이언트 애플리케이션에게서 액세스 토큰을 통해
받는 요청이 발생할 때마다
리소스 서버는 승인 서버를 실행시켜야 합니다
이에 따라 불필요한 교류 체증이 생깁니다
혹은 접근이 원활하게 이루어지지 않을 수도 있습니다
두 번째 접근법은
승인 서버와 리소스 서버가 모두
공통 데이터베이스를 사용하는 것입니다
승인 서버가 할 수 있는 것은
액세스 토큰을 클라이언트 애플리케이션에
발급하려고 할 때마다
이 데이터베이스 내에 엔트리를 만드는 것입니다
그리고 동일한 액세스 토큰이
클라이언트 애플리케이션으로부터 리소스 서버로 보내졌을 때
리소스 서버는 데이터베이스에 질문할 수 있습니다
만약 액세스 토큰이 공통 데이터베이스에서
원활한 상태로 존재한다면
클라이언트 애플리케이션으로 긍정적인 답변을
보낼 수 있을 것입니다
그리고 마지막 접근법은
우리가 함께 실행해볼 접근법입니다
먼저, 리소스 서버가
승인 서버로 연결이 되어야 합니다
웹 애플리케이션이 시작할 쯤 연결이 됩니다
그리고 나면, 승인 서버로부터 공개 인증서를
받을 수 있습니다
이 동일한 공개 인증서를 사용하여
인증 서버로부터 발급되는
액세스 토큰을 발급받을 때마다
액세스 토큰의 조작에 대한 진위 여부를 파악할 수 있습니다
공개 키를 사용해서 말이죠
이는 디지털 시그니처의 도움을 통해
JWT 토큰 부분에서 논의했던 것과
굉장히 유사하게 작동됩니다
이 접근법에서는
승인 서버와 리소스 서버 간에
지속적으로 필요한 소통이
존재해서는 안됩니다
오직 첫 번째 시도에만 리소스 서버가
승인 서버로 연결될 것이고
이는 승인 서버로부터
공개 인증서를 받기 위한 것입니다
이러한 이유로, 이것이 여러분을 포함한 다른 사람들에게
가장 많이 추천될 법한 접근법입니다
그리고 산업 내에서 이 접근법이 가장 많이 보일 것입니다
이에 따라, 리소스 서버가 액세스 토큰을
확인하기 위해 승인 서버에 연결되면서
가지게 되는 다양한 선택지에 대해
완벽히 이해가 가실 것이라고
생각합니다
감사하고, 다음 강의에서 뵙겠습니다
수고하셨습니다