이번 강의에서는
OAuth2 프레임워크 내부에 존재하는
PKCE grant type flow의 예시를 보겠습니다
이를 위해 oauth.com/playground로 왔습니다
먼저 PKCE flow에서 사용할
클라이언트와 사용자를 만들어야 합니다
이걸 클릭해보겠습니다
클라이언트를 등록하려고 합니다
지금 클라이언트 정보와 사용자 정보는
이미 생성되어 있습니다
User Account 정보를
새로운 탭에 열어서 참고하겠습니다
그리고 Continue 버튼을 클릭합니다
그 다음 이 PKCE 버튼을 클릭하여
필요하다면 이 설명을 읽을 수 있습니다
PKCE가 무엇인지 아직 잘 이해가 안 되신다면
이것을 읽어보실 수 있습니다
이제 첫 번째 단계로
제 클라이언트 애플리케이션은
code verifier와 challenge를 생성해야 합니다
code_verifier는 무작위로 생성되는 값이죠
Generate Code Verifier를 클릭합니다
이게 제 code_verifier이며
이게 제 클라이언트 애플리케이션이
code_challenge를 생성하기 위해
무작위로 생성된 수인
code_verifier에 적용해야 하는 식입니다
이 알고리즘은
SHA256 해시 알고리즘이라고 부릅니다
그럼 이 해시 알고리즘은 무엇을 출력할까요?
BASE64-URL-인코딩이 된 값을 출력합니다
Generate Code Challenge를 누르겠습니다
이게 제가 얻은 code_challenge 값입니다
code verifier와 code challenger를
클라이언트 애플리케이션이 생성했다면 이제는
나중에 인증 서버에 전송할 수 있도록
code verifier 값을
저장해 놓아야 합니다
첫 번째 단계에서는
code challenge 값만을 전송할 겁니다
Continue 버튼을 클릭하겠습니다
이제 두 번째 단계인데
여기 실사용자가 리다이렉트될 URL이 보입니다
인증 서버에 실사용자를 저희가 리다이렉트할 때
response_type 값은 code로 해야 합니다
다음으로 클라이언트는 언제 준비가 완료되는가?
리다이렉트 URI는 무엇인가?
scope는 무엇인가?
state는 무엇인가?
그리고 가장 중요한 이전에 보냈던 code challenge는 무엇인가?
등에 답해야 합니다
또한 code challenge method 값
즉 S256도 함께 전송해야 합니다
문제가 없는 걸 확인했으면
Authorize 버튼을 클릭하면 됩니다
이러면 실사용자는
인증 서버의 로그인 페이지로 리다이렉트 됩니다
여기에 아이디와 비밀번호를 입력하면 됩니다
이게 로그인에 사용할 아이디입니다
여기에 붙여넣고
비밀번호도 여기 있습니다
여기 나와 있는 비밀번호를 붙여넣습니다
이제 Log In 버튼을 클릭하겠습니다
Approved 버튼을 클릭하면
접근 권한을 주는 게 됩니다
세 번째 단계에서는 우선
state 값에 문제가 없어
CSRF 공격이 발생할 위험이 없도록 해야 합니다
그 다음 이건 인증 서버에서 받은
인증 코드 값입니다
인증 서버는 이 동안
이전에 보냈던 code challenge 값을
인증 코드 값에 대응하여 저장할 겁니다
저희가 처음 보냈던 state 값과
이 값이 일치한다면
It Matches, Continue!를 클릭하면 됩니다
이제 액세스 토큰을 얻는
네 번째 단계에서는 클라이언트가
이 URL로 POST 요청을 보내야 하며
이번에 Body 안에 보내야 하는
값은 grant_type
즉 인증 코드
클라이언트 ID
그리고 클라이언트 secret은
애플리케이션이 공개적이면 선택 사항입니다
하지만 지금 저희 클라이언트 애플리케이션은
공개 클라이언트가 아닙니다
그러므로 playground 사이트에서는
이 클라이언트 secret 값을 보내는 겁니다
하지만 선택 사항이라는 점을 기억하시길 바랍니다
그 다음에는 보내야 하는 리다이렉트 URL이 있고
저희가 받은 인증 코드가 무엇인지 나와 있습니다
마지막으로 보내려고 하는 중요한 정보는
code challenge를 얻기 위해
사용한 code verifier가 무엇인지 입니다
인증 서버는 같은 code verifier를 시용하여
새로운 code challenge를 생성하고
새로운 code challenge를 얻어서
이전에 받은 code challenge와
새로 계산한 code challenge의 값을
비교할 겁니다
둘이 일치하고 code challenge도
인증 코드에 대응한다면
인증 서버는 저에게
액세스 토큰과 새로고침 토큰을 발급할 겁니다
이게 바로 PKCE flow입니다
이해가 되셨길 바랍니다
이건 아주 중요한 부분입니다
원하신다면 이 사이트에서
얼마든지 시험해 볼 수 있습니다
하지만 PKCE flow는
반드시 이해하셔야 합니다
PKCE flow는
정말 안전하고 안정적인 것으로 유명해서
이제는 온갖 종류의 클라이언트 애플리케이션에
PKCE flow가 사용됩니다
공개 클라이언트, 모바일 애플리케이션
사설 클라이언트 등등 모든 시나리오에서
PKCE가 사용됩니다
심지어는 곧 발매 예정인
OAuth 2.1 명세 사항에
인증 코드와 PKCE를 합쳐서
그 grant flow를
authorization code + PKCE라 부르기로 했습니다
그러므로 PKCE는 인증 코드 flow를 따르고자 하면
클라이언트 secret을 이용할 것인지를 불문하고
필수적인 것이 될 겁니다
그리고 client credentials에는 변화가 없으며
device grant flow도 변화가 없습니다
하지만 2.0과 2.1을 비교해 보면
위의 그림이 2.0에 대한 설명이고
아래 그림이 2.1에 대한 설명입니다
2.0을 보시면 PKCE의 flavor가 여러 개라서
PKCE for SPAs, PKCE for mobile
PKCE for confidential clients 등이 따로 있습니다
그래서 상당히 혼란스럽습니다
그래서 이를 해결하기 위해
아예 인증 코드와 PKCE flow를 통합하기로 했습니다
또한 동시에 보안성이 떨어지는
resource owner credentials grant type flow와
implicit grant type flow와 같은 유형이 없어집니다
방금 언급한 두 유형은
2.1에서는 완전히 사라집니다
자 저희가 이 강의에서
OAuth2와 OpenID에 다룬 내용만으로도
2.1 버전에서도
문제가 없을 것 입니다
저희가 이 강좌에서 다루는 flow는
모두 2.1에서도 존재하기 때문입니다
이걸로 PKCE는 모두 이해하셨을 거라 믿습니다
다음에는 PKCE를
Angular UI 애플리케이션에 적용하여
백엔드 SpringBoot 애플리케이션과 연결시킴으로써
EazyBank UI 애플리케이션 테스트를 시작하도록 하겠습니다
들어주셔서 감사하며 다음 강의에서 뵙겠습니다
수고하셨습니다