현재로서는
우리의 Spring Boot 웹 애플리케이션 내에
모든 비즈니스 로직, 보안 로직
인증과 인가 조건을 써두었고
모든 걸 단 하나의 웹 애플리케이션에 모아두었습니다
단일 웹 애플리케이션만을
가지고 있는 단체들의 경우
이것이 적용될 수 있습니다
하지만 만약 본인의 단체가 여러 개의 웹 애플리케이션
혹은 모바일 앱이나 microservices를 소유하고 있다면
이런 상황에 추천할 만한 효과적인 방법은
보안 로직, 인증, 그리고 허가 로직을
항상 분리하는 것입니다
생각해보면
은행을 현실적인 예시로 볼 수 있습니다
은행은 터넷 뱅킹 웹 애플리케이션이나 모바일 앱을 가질 수 있고
몇 몇의 microservices
혹은 내부 웹 애플리케이션을 가지고 있을 수도 있습니다
대출 처리의 경우, 대출 승인
즉, 인증과 허가 조건을 유지하기 위해서
이 웹 애플리케이션 각각의 내부와
모바일 앱은 번거로운 역할을 하고 있습니다
이러한 안티 보안 로직을
공통 컴포넌트로 옮겨야 합니다
이를 통해 본인의 모바일 앱, microservices를 포함한
모든 웹 애플리케이션이
엔드 유저의 허가와 인증을 위해
이 공통 컴포넌트와 함께 작동할 수 있을 것입니다
이와 동일한 성과를 얻으려면
우리는 산업 내에 존재하는 고급 옵션을 모색해야 합니다
우리가 허가와 인증에 대해
이야기할 때마다
동일하게, 우리는 OAuth2에 대해 파헤쳐 보겠습니다
OAuth2는 업계 표준입니다
우리가 보안, 허가와 인증에 대해
이야기 할 때면
Google, Facebook, GitHub, Netflix와 같은
많은 기업 단체들의 경우를 살펴 봅니다
많고 많은 대기업들이
OAuth2을 활용합니다
그들의 웹 애플리케이션 내에서
인증과 허가를 실행하기 위한 것입니다
따라서 이 부분에서
우리는 단순히 OAuth2 구조물에 대해 이야기할 것입니다
우리는 이에 대한 모든 것을 배워서
이 지식을 바탕으로
우리의 웹 애플리케이션에 적용해보도록 하겠습니다
하지만 제가 OAuth2 구조물에 대한
설명을 이어나가기 전에
먼저 OAuth2가 해결하고 있는 업계의 문제점에 대해
설명하려고 합니다
OAuth2가 해결하는
업계의 첫 번째 문제점을
예시와 함께 설명하겠습니다
동일하게 TweetAnalyzer 웹 애플리케이션이 있다고
가정해보겠습니다
이는 그저 가상의 애플리케이션인거죠
트위터를 사용하고 있다고
가정해 봅시다
트위터를 사용하면서, 주기적으로 트윗을 작성하겠죠
리트윗도 할 것이고, 당신의 트윗을 좋아해주는
팔로워들도 분명히 있을 것입니다
트위터 앱의 사용자로서
당신의 트위터 정보에 대해 분석하고 싶을 것입니다
당신이 얼마나 자주 트윗을 쓰는지
일간, 주간으로
몇 개의 트윗을 작성하고 있는지
몇 개의 좋아요를 받고 있는지
몇 개의 리트윗을 받고 있는지 등을 말입니다
여러분이 이해하고 싶은 정보가 이 정도쯤 되겠죠
동일하게 가상의 웹 애플리케이션인
TweetAnalyzer 웹사이트를 상상해보십시오
이 웹사이트가 여러분의 트윗 데이터를 분석할 것입니다
그리고 메트릭스를 생성하는데
이 메트릭스로 트위터의 데이터를 이해할 수 있습니다
시나리오는 매우 간단합니다
트위터 유저가 제 3의 웹사이트를 사용하고 싶어합니다
사이트의 이름은 TweetAnalyzer이고 이는 트위터를 분석하기 위한 것이죠
현재로서는 트위터 앱 내에 존재합니다
이 시나리오에서 제 TweetAnalyzer는
트윗의 데이터를 분석하기 위해서
트위터 애플리케이션 내의 모든 정보가 필요합니다
왜냐하면 트위터 애플리케이션은
제 트윗에 대한 정보를 모두 담고 있기 때문이죠
몇 개의 트윗을 썼는지, 몇 개의 좋아요를 받게 됐는지 등이요
이러한 정보들이 트위터 앱 내에 있는 것입니다
만약 제 TweetAnalyzer가 트위터 앱에게
특정 사용자의 정보를 달라고 요청한다면
트위터 앱은 응하지 않을 것입니다
따라서 이것을 해결하기 위해서는 TweetAnalyzer가
트위터 사용자에 대한 인증서를 요구할 것입니다
따라서 제 3의 사이트인 TweetAnalyzer는
트위터 인증서를 공유해달라고 요구할 수 있습니다
동일한 인증서를 사용하여
계정에 로그인하고 데이터를 분석할 수 있는 것이죠
따라서 OAUTH2 구조물이 발명되기 전에
모든 엔드 유저들은
TweetAnalyzer와 같은 제 3의 웹 애플리케이션에게
본인의 인증서를 공유해야 했습니다
만약 이러한 시나리오가 있다면 말이죠
본인의 인증서를 제공한다면
TweetAnalyzer도 분명히
여러분의 인증서를 사용할 수 있을 것입니다
이를 바탕으로 의뢰인이 이해할 수 있게끔
데이터를 분석하고 레포트를 생성할 수 있습니다
하지만 매우 큰 단점이 있습니다
본인의 인증서를
제 3의 웹 애플리케이션에게 주는 것이기 때문에
남용되거나 다른 목적으로 쓰일 수 있습니다
예를 들어 여러분의 트윗을 분석하고
비밀번호를 바꾼다던지
이메일을 바꾸거나 잘못된 트윗을 남발할 수도 있습니다
이 모든 것이 제 3의 웹 애플리케이션을
신뢰한다면 생길 수 있는 일입니다
따라서 이것이 업계에서 제 3의 웹 애플리케이션에게
실제 인증서를 공유하지 않고
임시적인 접근을 허용할 수 있는
방안을 모색했던 것입니다
제 3의 웹 어플리케이션에게 제한된 접근을
허용하면서 본인들의
업무를 해내기 위해서 말이죠
이것은 OAUTH2 구조물이 해결하고자 했던
가장 보편적인 문제점입니다
OAuth2를 통해, 트위터 사용자들은
본인의 계정 인증서를 공유할 필요가 없어졌습니다
OAUTH2를 통해 트위터 엔드 유저 또한
제 3의 웹 애플리케이션에게
트위터 계정 인증서를 공유할 필요가 없어졌습니다
대신에, 트위터 앱이 분석 웹사이트에
임시적인 접근 토큰을 부여할 수 있도록
제한된 접근을 허용하였습니다
예를 들어, 트윗의 데이터를 읽기만 하고
새로운 트윗을 쓸 수는 없다든지
혹은 비밀번호를 변경할 수 없는 접속과 같은 것이죠
왜냐하면 TweetAnalyzer에게 발급되는 접근 토큰은
매우 제한된 접근만 허용되어서
트윗을 읽는 것만 가능하기 때문입니다
이 모든 것이 OAuth2 구조물을 통해 가능했습니다
여러분은 몇 가지 의문을 품으실 것입니다
예를 들어, 어떻게 발생할 것인지
트위터 앱이 접큰 토큰을 어떻게 발생시킬지
그리고 제 3의 웹 애플리케이션에
어떻게 넘겨줄 것인지 말입니다
여러분은 이러한 유형의 질문을 가지고 있겠지만
이것은 그저 시나리오일 뿐이며 저는
우선 예시를 제시하고, 이 예시를 바탕으로
앞으로의 강의시간 동안
많은 논의를 해보려고 합니다
이 논의를 통해 여러분의 의문이 해결될 것입니다
석기 시대 접근법을 보면
OAUTH2 구조물 이전에 사람들이 어떻게
TweetAnalyzer 시나리오를 해결했는지 보았을 때
TweetAnalyzer 웹사이트가 있는 것을 볼 수 있습니다
이는 당신이 트위터 계정 인증서를 공유해주면
이를 남용하지 않겠다고
굳은 약속을 하였습니다
당신은 엔드 유저이기 때문에 별 다른 선택의 여지가 없고
제 3의 웹 애플리케이션의 맹세를 믿는 수밖에 없죠
그리고 이 웹사이트에게
트위터 계정의 인증서를 전달합니다
그리고 본인의 인증서를 가지고 있기 때문에
제 3의 웹 애플리케이션이
인증서를 남용할 가능성이 매우 큽니다
즉, 이것이 석기 시대 접근법입니다
OAUTH2가 발명되기 전이죠
이 접근법은 더 이상 효과가 없습니다
OAUTH2는 이 시나리오에서 어떻게 도움이 될까요?
우리는 확실히 이것에 대해
앞으로 강의를 하면서 논의해보겠습니다
이제 OAUTH2가 해결하고자 했던
다른 문제점에 대해 논의해봅시다
여러분은 Google이 어떻게 모든 웹 애플리케이션에
매번 같은 인증서를 사용하게 해주는지에 대한
의문을 가져본 적이 없나요?
아시다시피 Google은 대기업입니다
수많은 제품과 웹 애플리케이션이 있죠
모바일 애플리케이션은 Gmail
Google Maps 그리고 YouTube도 있습니다
Google Photos와 Google Drive도 있죠
즉, 여러가지 다양한
웹 애플리케이션이나 모바일 애플리케이션이 있지만
모두 동일한 인증서를 허용합니다
매번 다른 인증서를
발급받거나
웹 애플리케이션에 여러가지 다른 계정을
등록할 필요가 없습니다
이것은 OAUTH2 구조물의 도움 덕분에 가능합니다
OAUTH2 는 항상 별개의 인증 서버를
유지할 것을 강조합니다
이 서버에는 인증과 권한의 로직이
존재하는 것이죠
따라서, 내부적으로 Google이 하는 일은
어떤 이가 이들의 제품 중 하나에
로그인을 시도한다면
사용자명과 비밀번호를 허용하고
이런 세부 사항들을
또 다른 요소인 승인 서버로 보내는 것입니다
그리고 모두가 같은 승인 서버를
향하고 있기 때문에
동일한 인증서가 허용될 수 있는 것이죠
그리고 미래에 Google이 승인 로직이나 권한 로직에
변화를 주고 싶다면
그들이 변화시켜야 할 곳은
딱 한 곳입니다
그것이 OAUTH2의 장점이고요
또다른 장점은
경험에 본 적이 있을 수도 있지만
Gmail에 로그인했을 때
YouTube로 또 다시 로그인할 필요가 없다는 것입니다
또 다른 창으로 YouTube를 열자마자
로그인 세부 사항이 자동적으로 인식될 것이고
YouTube, Google Photos 등에 적용될 것입니다
이 모든 것은
OAUTH2 구조물의 도움이 있기에 가능합니다
우리가 접근 토큰을 다른 웹사이트들과 공유하고
모든 제품들이 뒤에서 같은
승인 서버로 향해 있기 때문에
문제가 있을 수가 없는 것이죠
그것이 바로 OAUTH2의 힘입니다
기억해야 할 주요 사항은
OAUTH2가 별도의 승인 서버를 사용하는 것을
지향한다는 점입니다. 승인과 권한의
역할을 하기도 하죠
이 점이 분명하게 드러났으면 좋겠습니다
그리고 또다른 유사한 문제점에 대해 알아봅시다
은행 단체가 있다고 생각해봅시다
이 은행 단체에는 대출 처리, 카드 처리, 정보 처리를
도맡아 하는 다양한
애플리케이션이 있을 것입니다
만약 엔드 유저로서
은행 애플리케이션이 모든 엔드 유저들에게
각기 다른 애플리케이션이기 때문에
개별적으로 등록해달라고 부탁한 후
모두 다른 사용자명과 비밀번호를 유지해달라고 한다면
상식적으로 말이 되지 않을 것입니다
왜냐하면 엔드 유저에 의하면, 단일 개체이기 때문이죠
은행의 다른 모든 웹 애플리케이션이나
모바일 애플리케이션 때문에
왜 모두 다른 인증서를 발급받아야 하나요?
여기서 OAUTH2가 등장합니다
왜냐하면 OAUTH2을 통해서
모든 웹 애플리케이션들이
단일 승인 서버로 향할 수 있게 되었기 때문입니다
그리고 사용자의 세부 사항들을
개별적인 데이터 베이스에 보관하게 되었습니다
그들은 별도로 공통 컴포넌트를 가질 수 있습니다
이 컴포넌트가 승인 서버입니다
따라서 OAUTH2가 없었을 시절에는
화면에 보이는 것처럼 애플리케이션마다
데이터베이스 속에
다른 계정을 설정하는 것이
당연했습니다
하지만 OAUTH2가 등장하자
모두가 별도의 공통 컴포넌트를 두고 있습니다
즉, 승인 서버를 두고 있는 것이죠
이 서버는 단체 내에 애플리케이션의
승인과 권한을 관리합니다
이것은 OAUTH2가 해결해낸
몇 가지의 보편적 문제점입니다
완벽히 이해가 되셨으면 좋겠네요
다음 강의에서는, OAUTH2 구조물이 무엇인지에 대해
쉽고 빠른 소개를 해보겠습니다
감사하고, 다음 수업에서 뵙겠습니다
수고하셨습니다