이전 강의에 저희는
두 개의 다른 애플리케이션이
API 간 커뮤니케이션을 통해
서로 소통하고자 하는 시나리오를 통해
client credentials grant type flow에 대해 알아보았습니다
이번에는 authorization code grant type flow에 대해 알아보겠습니다
이 flow는 실사용자가 연관되었을 때
사용하게 됩니다
REST API는 리소스 서버에
모두 노출이 되어 있고
서드 파티 UI 애플리케이션
또는 저의 UI 애플리케이션이
리소스 서버 내부에 있는
REST API를 호출하려고 하는 시나리오입니다
하지만 리소스 서버는 access token을 요구하기 때문에
클라이언트 UI 애플리케이션은
KeyCloak 인증 서버와 연결해서
access token을 받은 다음 그 token을
리소스 서버에 넘겨야 합니다
이것이 실사용자가 관여하는 상황에서
따르게 되는 시나리오입니다
하지만 저는 이번에 시나리오를 설명드릴 때
Angular UI 애플리케이션을 사용하지 않을 것입니다
왜냐하면 Angular UI 애플리케이션은
JavaScript 애플리케이션이기 때문입니다
JavaScript 애플리케이션들은
코드가 공개되어 있어
클라이언트 secret을
JavaScript 코드 또는 UI 코드에 안전하게 보관하는 것이 불가능합니다
왜냐하면 브라우저의 JavaScript 코드를 보는 것만으로
누구든지 클라이언트 secret을 찾을 수 있기 때문입니다
그래서 JavaScript 애플리케이션을
UI 애플리케이션으로써
백엔드 리소스 서버와 소통하는 데 사용할 때에는
다른 방식으로 접근해야 합니다
앞으로의 강의에서 그러한 접근 방법을 다룰 것입니다
하지만 지금은 UI 애플리케이션이 있다고만 생각하시면 됩니다
Thymeleaf, JSPs 와 같은
백엔드 서버에 쉽게 secret 저장이 가능한
templating 언어의 도움으로 만든 애플리케이션입니다
그렇게 만든 애플리케이션이라면
제가 지금 이야기할 내용은
모두 적용 가능하다고 보셔도 됩니다
여기서 보이듯이
Authorization code grant type flow는
실사용자, 클라이언트, 인증 서버
그리고 리소스 서버가 관여합니다
지금은 이전에 구축했던 인증 서버, 리소스 서버
그리고 인증 서버 내부에 생성했던
클라이언트를 사용할 수 없습니다
왜냐하면 전에 생성했던 클라이언트는
client credentials grant type에만 사용 가능하기 때문입니다
그러므로 인증 서버 내부에서
authorization code grant type flow에 적용되는
새로운 클라이언트를 생성해야 합니다
또한 클라이언트 정보와는 별도로
인증 서버 내부에 실사용자 정보도 생성하여
저희가 가지고 있는
EazyBank 리소스 서버를 가지고
authorization grant type flow를 모방해 보겠습니다
그러니 다음 강의에서는 KeyCloak 인증 서버에
클라이언트와 실사용자 정보를 생성하겠습니다
들어주셔서 감사하며 수고하셨습니다