이번 강의에서는
클라이언트 인증서 grant type 플로우에 대해
이해를 해보도록 합시다
OAuth2 구조물 속에 위치한 것 말이죠
여기서 볼 수 있듯이
엔드 유저는 연관되어있지 않습니다
오직 클라이언트 애플리케이션
Auth 서버
리소스 서버만 연관되어 있습니다
이 grant type 플로우는
엔드 유저가 관련되어있지 않을 때마다 사용할 수 있습니다
또한 두 개의 백엔드 애플리케이션에 관한 상황이나
두 개의 microservices 애플리케이션이
서로 소통하려는 상황에서 쓰입니다
아마 이러한 두 개의 백엔드 애플리케이션이나
microservices 애플리케이션이
다른 단체에 소속되어 있지만
서로 교류를 희망하기 때문일 것입니다
여기서, 클라이언트가
microservices 애플리케이션이라고 생각할 수 있습니다
A 단체에 소속되어 있다고도 생각할 수 있습니다
그리고 이 A 단체 클라이언트 microservice는
B 단체의 리소스 서버 내에
배포되어있는 microservices와
교류하고 싶은 것입니다
그들이 서로 교류하고 싶다면
클라이언트 microservice나
클라이언트 서비스가
확실히 Auth 서버와 연결을 해야 합니다
액세스 토큰을 얻어야지만
B 단체의 리소스 서버와
연결할 수 있기 때문입니다
그 이유는, Auth 서버와 리소스 서버가
같은 B단체에 소속되어있기 때문입니다
이와 더불어, 이 플로우를 세부적으로 이해해보도록 합시다
가장 처음에는
클라이언트 애플리케이션이 Auth 서버로
세부 사항을 보낼 것입니다
"클라이언트 인증서 보내드립니다
엔드 유저는 관련되어 있지 않습니다
제 클라이언트 인증서를 확인해주시고
접근 토큰을 발급해주십시오"라고 말이죠
클라이언트 인증서가 확인되면
Auth 서버가 클라이언트 애플리케이션으로
액세스 토큰을 발급할 것입니다
그리고 클라이언트 애플리케이션이 접근 토큰을 발급하면
리소스 서비스 내에서 실행 가능한 서비스에게
직접적으로 전달이 될 것입니다
만약 액세스 토큰이 적절하다면
리소스 서버는 클라이언트 애플리케이션에게
그에 응하는 답변을 할 것입니다
이것은 매우 단순한 OAuth2 플로우이며
엔드 유저가 연관되지 않은
여러 상황들에 영향을 미칠 수 있습니다
자 이제, 액세스 토큰을 받지 못하려면
클라이언트 애플리케이션이 어떠한 요청을 Auth 서버에
보내야 하는지에 대해 파악해봅시다
보시다시피, 가장 첫 번째 단계는
클라이언트 애플리케이션에 달려있습니다
Auth 서버에 액세스 토큰에 대한
요청을 보내야 한다면
"client_id, client_secret"를 보내고
스코프 값이 무엇인지
무엇을 원하는지 그리고
읽기 권한을 원하는지 쓰기 권한을 원하는지를 정해야 합니다
스코프 값 이후에
"grant_type as client_credentials"를 보내야 합니다
따라서 Auth 서버가
"grant type as client_credentials"를 받게 된다면
엔드 유저가 연관되어있지 않다는 것을 인지할 것입니다
만약 client_id와 client_secret가 적절하다면
바로 클라이언트 애플리케이션에게
액세스 토큰을 전송할 것입니다
그리고 만약 연관성이 불분명하다면
CSRF 토큰을 전송받을 이유가 없을 것입니다
왜냐하면 모든 소통과 교류가 브라우저를 통해
발생하지 않을 것이기 때문입니다
그리고 브라우저가 존재하지 않는다면
CSRF 공격의 가능성이 존재하지 않기 때문입니다
지금 이 개념이 확실하게 이해되셨을 거라고 짐작합니다
다시 한 번 말하자면, 이 플로우를 oauth.com에서
테스트할 방법은 없습니다
왜냐하면 브라우저의 도움을 받으면서
이 서비스를 시험할 수 없기 때문입니다
하지만 제가 데모를 드리겠습니다
이 데모는 클라이언트 인증서 grant type를 다룬 것이며
Postman의 도움을 통해
Auth 서버에 요청을 보내고
액세스 토큰을 얻을 수 있도록 합니다
그리고 동일한 액세스 토큰은
리소스 서버에 전송할 수 있습니다
Postman의 도움을 통해서 말이죠
따라서, 클라이언트 인증서 grand type에 대해
의문점이 생기셨더라도 잠시 기다려주시기 바랍니다
이해가 다 되셨을거라 믿습니다
감사하고, 다음 강의에서 뵙겠습니다. 수고하셨습니다