이 강의에서는
암시적 인증 유형 플로우에 대해 이야기 해보도록 하겠습니다
앞서 언급했던 것처럼, 이것은 덜 안전하고
모두가 인증 코드 유형 플로우 사용을 권장하기 때문에
과거에도 잘
사용되지 않았습니다
그리고 OAUTH2.1 버전에서는
완전히 제거될 예정입니다
암시적 인증 유형에 대해 알아봅시다
인증 코드 유형 플로우와
암시적 인증 플로우의 차이를
인식할 수 있도록 말이죠
첫번째 단계로, 엔드 유저 혹은
리소스 소유자는 클라이언트 애플리케이션에게
"리소스 서버에 저장되어 있는
제 사진이나 트윗과 같은
리소스에 접근하고 싶습니다"라고 말합니다
이에 대한 회신으로, 클라이언트 애플리케이션은
엔드 유저에게 말할 것입니다
"네, 승인 서버로 이동하겠습니다"
"인증서를 입력해주십시오"
"인증이 완료되었다면
리소스에 접근하는 행위에 대한
허가를 내려주십시오"라고 말이죠
이제, 엔드 유저는 인증 서버 로그인 페이지로
다시 이동하게 될 것입니다
여기서 엔드 유저 혹은 리소스 소유자가
그의 신원을 증명하기 위해 인증서를 입력할 수 있습니다
본인의 허가도 증명할 수 있겠죠
이 과정이 성공적으로 이루어진다면
인증 서버는 액세스 토큰을 발급할 것입니다
이 과정의 사이에는 인증 코드가 존재하지 않습니다
모든 단계에서 클라이언트 애플리케이션은
액세스 토큰을 받게 됩니다
그리고 이 액세스 토큰을 사용하여
클라이언트 애플리케이션은 리소스 서버로
요청 사항을 남깁니다
만약 액세스 토큰이 적절하다면
리소스 서버는 적절한 답변으로
회신할 것입니다
그리고 이 암시적 인증 플로우가 덜 안전한 이유는
플로우 도중에 인증 서버에게
보내야 하는 세부 사항 항목들을
이해해본다면 알 수 있습니다
우리는 클라이언트 ID와 redirect URI, 그리고
스코프와 상태, 답변 유형만 전송해야 합니다
답변 유형 값은 토큰이겠죠
하지만 이것이 get 요청이기 때문에
인증 서버로 클라이언트 기밀을 보내는
의미가 없을 것입니다. 왜냐하면 get 요청에서
클라이언트 기밀을 보낼 때마다
여러분의 URL에 있는 모든 것이 노출되기 때문입니다
이것이 암시적 인증 플로우에서 클라이언트 애플리케이션이
클라이언트 기밀을 공유할 필요가 없는 이유입니다
이와 더불어, 심각한 문제점이 있습니다
누구나 트윗 분석 애플리케이션인 척을 하고
승인 서버에게 요청을 할 수 있다는 점입니다
이것이 첫 번째 결점입니다
그리고 두 번째 결점은
우리는 get 요청을 하고 있는 중이므로
인증 서버로부터의 답변이
get 답변일 것입니다
그리고 액세스 토큰은 인증 서버가
클라이언트 애플리케이션으로 도로 발급할 때마다
URL의 일부분으로 등장하게 될 것입니다
다시 말하지만, 이는 매우 위험합니다
어느 해커든지, 이 액세스 토큰을 가지고
CSRF 토큰 값을 바꾸지 않고
액세스 토큰을 편집하려고 할 수 있습니다
이 플로우에는 결점이 너무 많고
OAUTH2 인증 유형 플로우 내에서
이 암시적인 인증 유형을 안정적으로 만들 수 있는
방법이 존재하지 않기 때문에
새로운 플로우, 즉 허가 코드 인증 유형 플로우가
만들어진 것입니다
저희는 이전 강의에서 이에 대해 알아보았습니다
하지만 요즘에는 이 플로우가
유산 애플리케이션 내에서 혹은
단체의 사내 애플리케이션에서 사용됩니다
하지만 이러한 암시적인 인증 플로우가 사용되는 것을 볼때마다
염려하는 건축가들이나 개발자들에게
이것이 덜 안전한 플로우이며
허가 코드 인증 유형 플로우를 사용하는 것이
더 좋을 것이라는 점을 안내해야 합니다
이와 더불어, 암시적인 인증 유형 플로우에 대한
단순한 데모를 만들어봅시다
여기, 동일한 OAUTH2.0 playground 웹사이트에서
우리에게는 암시적인 선택지가 있습니다
이 '암시적인' 버튼을 눌러보겠습니다
가장 첫 번째 단계에서 클라이언트 애플리케이션이
인증 URL을 만들고
리소스 소유자를 이 UR로
이동시킬 것이라는 걸 알 수 있습니다
이동시키는 도중에
답변 유형이 토큰이며
클라이언트 ID, 재전송 URI가 무엇인지
스코프와 상태가 어떤지 전송하였습니다
보시다시피, 클라이언트 기밀은 연관되지 않았습니다
'인증하기'를 누르자마자
인증 서버 페이지로 이동하게 될 것입니다
여기서는 다른 창에 있는
제 인증서를 입력할 수 있습니다
이것이 제 사용자명과 비밀번호입니다
일단 세부 사항을 입력하고 로그인 버튼을 눌러보겠습니다
'허가하기'를 누르자마자
승낙되는 모습을 볼 수 있습니다
제가 받게 되는 get URL 속의 접근 토큰을 볼 수 있고
상태값과 더불어
유효 기간 또한 알 수 있습니다
이 모든 세부 사항은 클라이언트 애플리케이션에게
get URL을 통해 공유되고 있습니다
다만, 상태값이 달라지지 않는 것을 확인하여
CSRF 공격이 없었던 것을 확신할 수 있습니다
하지만 보다시피 악의적인 상대가
클라이언트 안으로 액세스 토큰을 넣는 것은 막을 수 없습니다
OAUTH에는 해결방법이 없고
암시적인 플로우는 보호 능력이 없습니다
이러한 이유로 제거된 것이겠죠
상태값이 일치한다면
"일치합니다. 계속하기" 버튼을 눌러야 합니다
상태값이 일치하면
접근 토큰, 토큰 유형, 만료기간과 스코프를
추출할 것입니다
이는 URL의 한 부분에 나와있습니다
암시적인 인증 유형 플로우를 확실히 이해하고
왜 이것이 안전하지 않은지 파악하셨길 바랍니다
이러한 지식을 바탕으로
부디 암시적 인증 유형 플로우를 사용하지 마시길 바랍니다
엔드 유저가 연관되어있을 때에는
언제나 허가 코드 인증 유형 플로우를 사용하셔야 합니다
이를 끝으로, 다음 강의에서 만나도록 합시다
수고하셨습니다