이번 강의에서는
OAuth 2.0 framework에 대해
빠르고 간단한 소개를 해보도록 하겠습니다
OAuth는 Open Authorization를 의미합니다
OAuth 2.0의 숫자 2는
버전명을 뜻합니다
즉, OAuth 1.0는 더 오래된 버전이고
현재는, 모두가 OAuth 2.0을 사용하고 있죠
OAuth 2.0는 자유 오픈 소스 프로토콜입니다
오픈 소스 사회에서 개발되었죠
하지만 OAuth 2.0은 단순히 사양이라는 걸
명심해주세요
그저 우리가 웹 애플리케이션 내에서 승인이나 허가를 받을 때
따라야 하는 적정한 기준을
정의하고 있을 뿐입니다
이는 제품이나 서버가 아닙니다
우리가 직접적으로 영향을 끼칠 수 있는
실행 구조물도 아닙니다
단순히 사양 기준 규격일 뿐인거죠
이러한 기준과 사양을 바탕으로
산업 내에서 많은 제품들과
구조물들이 개발되고 있습니다
앞으로 진행될 강의에서 더 많은 이야기를 나눠보도록 하죠
하지만 지금으로선
OAuth 2.0가 단순한 사양
인터페이스나 프로토콜이기에
오직 기준만을 정의하며
실행 코드조차 존재하지 않는다는 것을
기억해주시길 바랍니다
우리가 이전에 이야기 나눴듯이
OAuth 2.0는 보안 기준 규격이며
한 애플리케이션이 다른 애플리케이션 내부에 있는
여러분의 데이터에 접속할 권한을 주는 것입니다
특히나 제 3의 웹 애플리케이션이
다른 애플리케이션 속에 있는
당신의 데이터에 접근하려 한다면
OAuth 2.0는 여러분이 고려할 수 있는
매우 훌륭한 선택지입니다
이제 특정한 상황을 가정해보죠
사진 편집 웹사이트 중 하나가
Google photos내에 있는
혹은 Google Drives내에 있는
여러분의 사진에 접근하기를 희망한다고 가정해봅시다
그들의 웹사이트에 여러분의 사진을 모두 업로드하여
여러분이 편집을 할 수 있도록 하는 것이죠
따라서 이 상황에서는 확실히
제 3의 웹 애플리케이션이 연관되어 있다는 것을 알 수 있습니다
우리는 Google password나
인증서를
제 3의 웹 애플리케이션이 사진을 업로드할 수 있도록
하기 위해서 제공할 필요가 없습니다
대신, OAuth 2.0 구조물을 이용하여
혹은 OAuth 2.0 프로토콜을 이용하여
우리가 가장 제한적인 허가를 내릴 수 있도록
하면 됩니다
제 3의 웹 애플리케이션에게 말이죠
그리고 이러한 제한된 허가를 통해
제 3의 웹 애플리케이션은
오직 사진을 보는 것만 가능할 뿐
편집을 하는 등의 다른 행위는 취할 수 없습니다
이것이 바로 OAuth 2.0 구조물의 장점이죠
우리가 이 허가를 어떻게 내릴 것이냐면
액세스(access) 토큰이라는 토큰의 도움을 받을 것입니다
액세스 토큰는 OAuth 2.0 프레임워크 내에서
굉장히 중요한 요소입니다
왜냐하면 오직 이 액세스 토큰만이
제 3의 웹 애플리케이션이 어떤 행위를 취할 수 있는지
어떤 권한을 가질 수 있는지
혹은 어떤 허가를 내릴 수 있는지 등을 결정할 수 있습니다
여러 부분들을 고려하였을 때
OAuth 2.0 액세스 토큰을
사무실이나 호텔의 전용 키라고 볼 수 있겠습니다
우리는 사무실 전용 키를 활용하여
이러한 제한들을 적용하는 것과 같으니까요
즉, 사무실에 들어가서도 아무데나 돌아다닐 수 없고
카드 키를 소유했을 때에만 제한된 공간에 접근할 수 있는
권한이 주어지는 것과 같다고 볼 수 있죠
OAuth 2.0 액세스 토큰도 비슷하다고 생각하시면 됩니다
제한이 강화되는 것이죠
OAuth 2.0 구조물의 또다른 장점은
여러 상황에서 다양하게 사용할 수 있는
Grant Types가 존재한다는 것입니다
Grant type은 인증의 한 종류이며
엔드 유저나 애플리케이션에 대한 승인입니다
이러한 grant types를 사용했을 때
액세스 토큰이 발급되는 것입니다
만약의 상황을 가정해봅시다
엔드 유저가 관련되었다면 분명히
grant type의 승인 코드를 따라야 합니다
그리고 유사하게, PKCE grant type
또한 JavaScript 애플리케이션 내에서 사용될 수 있습니다
혹은 단일 PKCE 애플리케이션에서 사용될 수도 있겠죠
또한 동시에 두 개의 microservices
혹은 두 개의 백엔드 애플리케이션이
서로 교류하려고 한다면
우리에겐 client credentials grant type가 있습니다
그리고 Apple TV나 Android Tv와 같은
장치들이 연관되어 있다면
우리는 device code grant flow를 따라야 합니다
그리고 유사하게, 우리에게는 refresh token grant flow
implicit flow 그리고 password grant flow가 있습니다
따라서 우리는 이러한
grant flows를 더 상세히 살펴보겠습니다
언제 사용하는 것인지, 어떻게 작동하는지에 대해 말이죠
하지만 명심해야 할 부분은
implicit flow와 password grant flow가
더 이상 사용되지 않으며 OAuth 2.1 사양에서는
제거될 것이라는 점입니다
제가 이 영상을 제작하는 시점에서는
OAuth 2.0가 최신 버전이지만
다음 버전인 OAuth 2.1도
현재 개발 중에 있다고 합니다
2.0와 2.1에 엄청난 차이점은 없습니다
제가 OAuth 2.0 or OAuth 2.1에 대한 최신 정보를
얻을 수 있는 좋은 웹사이트를
소개시켜드리겠습니다
여러분이 oauth.net/2로 이동하면
다음과 같은 웹페이지가 열릴 것입니다
이 웹페이지 내에서는 보시다시피
다양한 단말기에 관한 링크가 있습니다
이런 것들은 OAuth 2.0내에 존재하는
특수 용어들이나 grant types에 대한 것입니다
물론 우리가 더 세부적으로 이야기를 나눌 것이지만
제가 이런 정보를 미리 제공하는 이유는
여러분들이 더 많은 내용에 대해 알고 싶다면
언제든지 참고하시길 바라는 차원에서입니다
이 웹페이지에서 스크롤을 내리면
OAuth 2.1이라는 링크가 있습니다
보시다시피 색깔이 다르게 표시가 되어있으며
OAuth 2.0와 통합하기 위해서
과정에 대한 최신 정보가 올라와 있습니다
2.1의 주요 의도는
새로운 사양을 개발하기 위한 것이 아니라
중복되는 플로우를 제거하고
단순하고 깔끔하게 만들기 위한 것입니다
물론 다음 강의들에서 OAuth 2.0에 대해 이야기 할 때
이 부분은 다시 한 번 강조하도록 하겠습니다
여기서 블로그도 읽을 수 있는데
"OAuth 2.1의 때가 왔다" 이것을 클릭해보겠습니다
이 블로그에서 명확하게 다루는 것은
왜 이들이 새로운 버전인 OAuth 2.1를 개발하려고 하는지
그리고 OAuth 2.1로 얻으려고 하는 것이 무엇인지 입니다
여기를 보신다면
이것이 바로 OAuth 2.1의 발전 과정이고
이런 발전 과정을 거치면서
사람들이 이 모든 세부 사항을 기억하기에
매우 복잡한 상태가 되었습니다
그래서 그들이 2.1의 아주 단순화된 부분으로
개발하고자 하는 것입니다
그들은 이 implicit grant type flows와
password grant type flows를 제거하고
인증 코드와 PKCE를 하나로
병합할 것이라는 계획을 밝혔습니다
여기서 볼 수 있듯이
단일 grant flow가 된 이유입니다
그리고 동시에, 여기를 보면 'client credentials'
그리고 'device grant flow'도 있습니다
따라서, 전체적으로 그들은 2.0을 2.1로 단순화하려고 합니다
이것이 제가 이번 강의를 통해 전달하고자 하는 바이기도 하고요
이제 OAuth 2.0가 어떤 것인지에 대해
완벽히 이해가 가실 것이라고 생각합니다
감사하고 다음 강의에서 뵙겠습니다
수고하셨습니다