이번 수업에서는
OAUTH2 내부의 비밀번호 grant 혹은
리소스 소유자 인증서 grant type를
이해해보도록 합시다
몇몇 사람들은 이것을 플로우라고 부릅니다
리소스 소유자 인증서 허가 플로우
그리고 몇몇은 비밀번호 허가라고 부릅니다
모두 같은 플로우를 일컫는 말입니다
이 플로우 내부에서는 엔드 유저가 연관이 있습니다
그리고 클라이언트 애플리케이션이 인증 서버와
리소스 서버와 연관이 있습니다
가장 첫 번째 단계로
엔드 유저 혹은 리소스 소유자가 할 일은
클라이언트 애플리케이션과 소통하는 것입니다
엔드 유저는 "저는 이러한 리소스에 접근하고 싶습니다"
라고 말해야 합니다
그리고 클라이언트 애플리케이션에게
정확한 인증서를 주어야 합니다
클라이언트 애플리케이션이 Angular UI 애플리케이션일 수도
혹은 실제 인증서를 받는
UI 유형의 애플리케이션일 수도 있습니다
리소스 소유자가 인증 서버와 함께
등록한 것이겠죠
이 부분이 꼭 이해해야만 하는
가장 중요한 포인트입니다
엔드 유저가 인증 서버와 본인의 인증서를 공유한다는 것을
알게 되면 OAUTH2 플로우가
비밀번호 승인인지 혹은
리소스 소유자 승인 유형인지 파악할 수 있습니다
클라이언트 애플리케이션이 엔드 유저에게 실제 인증서를 받으면
게시 요청의 유형으로 인증 서버에게
특정 엔드 유저가 그의 리소스에
접근하고 싶어한다는 내용의 요청문을
전달하게 될 것입니다
이것은 엔드 유저의 인증서입니다
이 인증서들과 함께 클라이언트는
본인의 클라이언트 ID와
클라이언트 기밀도 넘겨주어야 합니다
인증 서버에 의해 세부 사항들이 모두 확인되었다면
액세스 토큰을 바로 발급할 것이고
클라이언트 애플리케이션이
액세스 토큰을 받게 된다면
동일한 토큰이 리소스 서버로 보내질 것입니다
만약 이 액세스 토큰이 적절하다면
리소스 소유자는 클라이언트 애플리케이션으로
적당한 답변을 회신할 것입니다
이 플로우에서, 가장 큰 결점은
엔드 유저와 리소스 소유자입니다
그는 실제 인증서를
클라이언트 애플리케이션과 공유합니다
그리고 이러한 이유로, 제품 애플리케이션에는
추천되지 않고 있습니다
이제 클라이언트 애플리케이션이 인증 서버에게
두 번째 단계에서 어떠한 세부 요청을 보내야지만
액세스 토큰을 받을 수 있을지에 대해
고민해보아야 합니다
두 번째 단계에서
클라이언트 애플리케이션은 클라이언트 ID과
클라이언트 기밀, 세부 사항과 함께 스코프를 보낼 것입니다
이와 함께 엔드 유저의 사용자명과 비밀번호도
넘겨주어야 합니다
그리고 사용자명과 비밀번호는 엔드 유저의
로그인 플로우를 통해서 클라이언트 애플리케이션에
제공되었을 것입니다
그리고 이 시나리오에서 꼭 언급해야 하는
인증 유형은 '비밀번호'입니다
이 인증 유형 값을 통해, 인증 서버는
자신의 클라이언트 애플리케이션이 어떠한
인증 유형 플로우를 고려하고 싶어하는지에 대해
높은 이해도를 가지게 됩니다
따라서 이 상황에서, 승인 서버가
비밀번호를 인증 유형으로 받게 된다면
클라이언트 애플리케이션이 리소스 소유자 인증서 유형을
따르고 싶어한다는 것을 알 수 있습니다
비록 제가 이 리소스 인증서 유형이 제품 애플리케이션에
추천되지 않는 유형이라고 말씀드렸지만
가끔은 특정 단체들에게서 쓰이는 모습을
볼 수 있습니다
특정 단체들이 이러한 인증 유형 플로우를 사용하는
모습을 볼 수 있는 상황은
클라이언트 애플리케이션, 인증 서버
그리고 리소스 서버가 모두 한 단체에 속해 있을 경우입니다
만약 제 인증 서버가 클라이언트 애플리케이션을 신뢰한다면
클라이언트 애플리케이션이
리소스 소유자의 인증서를 남용하지 않을 것이라는 뜻입니다
그리고 그들이 리소스 소유자 인증서 유형을 사용할 수도 있죠
왜냐하면 꽤 합리적인 의견이기 때문입니다
클라이언트 애플리케이션이
오직 한 단체에만 소속된다는 부분이 말이죠
하지만 몇몇 사람들은 동의하지 않습니다
그들은 언제나 허가 코드 인증 유형 플로우를
사용하자고 주장할 것입니다
이것이 이 인증 유형이 OAUTH2 이외의 프로그램에 없고
추후에 OAUTH2.1 버전에서도 제거될
예정인 이유입니다
이 플로우에 대해 잘 이해가 되셨으면 좋겠습니다
이 웹사이트에서 보시다시피
비밀번호 인증이나 리소스 소유자 인증서 유형이 없습니다
이는 인증서 유형이 OAUTH2.0 이후로
모두 제거된 상태이기 때문입니다
하지만 모두들 이 플로우가 내부적으로 어떻게 작동되는지
이해를 하고 계셨으면 좋겠습니다
플로우가 무엇인지, 왜 제품 애플리케이션에
추천받지 못하는지에 대해서 말입니다
다음 강의에서는
엔드 유저가 연관되어있지 않을 때 사용해야 하는
인증 유형 플로우에 대해 이야기해보도록 합시다
감사하고, 다음 강의에서 뵙겠습니다
수고하셨습니다