이번 강의에서는
OAuth2 샘플 플로우에 대해 보여드리겠습니다
TweetAnalyzer 시나리오를 통해서 말이죠
우리가 이야기하는 것은
가상의 시나리오라는 점을 명심해주세요
이 시나리오를 이해해보시길 바랍니다
어느 금요일
여러분은 스스로 웹사이트를 만들 수 있을 것이라는 아이디어가 떠오릅니다
트윗에 대한 정보를 분석하는 웹사이트 말이죠
여러분은 레포트를 실행시킵니다
여러분은 "와 정말 좋은 아이디어다"라고 생각하실 것입니다
하지만 이를 실현하기 위해서는
트위터 팀에 먼저 연락을 취해야 합니다
그래서 트위터 팀에 연락을 하고
이러한 아이디어가 있다고 설명을 드립니다
트위터팀도 아이디어를 마음에 들어합니다
그래서 여러분은 그들에게
이미 노출된 REST APIs가 없는지 묻습니다
"특정한 유저의 정보를
모을 수 있을까요?"
그리고 트위터 팀이 답변을 합니다
네 당연히 있죠
하지만 엔드 유저에게 액세스 토큰을 얻기 위해서는
이 Oauth2 구조물을 따라야만 해요
그리고 동일한 액세스 토큰을 제게 넘겨 주셔야지만
그 액세스 토큰을 바탕으로
그리고 허가를 바탕으로
리소스 서버에 있는 REST APIs를 실행시킬 수 있습니다
뒤에서는 어떤 일이 일어나고 있을까요?
여러분은 무척 신났겠죠
그리고 이를 시작하기 위해, 먼저 여러분을
트위터 애플리케이션에 클라이언트로 재등록해야 합니다
그러고 나서 트위터 팀에 다시 연락을 취하면
그들은 당신의 기본 정보에 대해 물을 것입니다
웹사이트 이름은 무엇인가요?
실명은 무엇이며 로고는 무엇인가요?
그리고 이러한 인증이 모두 끝난 후
클라이언트 ID와 클라이언트 기밀을 제공할 것입니다
클라이언트 기밀은 비밀번호나 마찬가지인데
잘 보관해두어야 합니다
이제 모든 준비가 끝난 것입니다
적절한 클라이언트 ID와 기밀이 있기 때문이죠
그리고 다음 단계에선, 당연한 것이지만
웹에서 마케팅을 해야 합니다
어떤 유저의 트윗 정보든 분석할 수 있으며
레포트를 생성할 수 있다고 홍보해야 합니다
그리고 리소스 소유자라고 부를 수 있는 유저 중 한 명이
여러분의 사이트를 방문하고 마음에 들어합니다
사이트를 사용하겠다고 마음을 먹은 것이죠
하지만 유저는 의문을 갖고 있습니다
"제 트위터 계정 정보를 이 사이트에
공유해야 하나요?"
당연히 아니죠
이 TweetAnalyzer 웹 사이트에는 '트위터를 통해 로그인하기'
라는 버튼이 있을 것입니다
그리고 엔드 유저가 클릭하면, 마법이 일어납니다
트위터 로그인 페이지로 이동하게 되는 거죠
클라이언트 애플리케이션으로서 유저가
인증 서버의 본래 페이지로 다시
잘 되돌아가는지 확인해야 합니다
여기 인증 서버가 있습니다
트위터 단체의 인증 서버입니다
즉, 그는 트위터 애플리케이션의 로그인 페이지로
다시 되돌아가게 될 것입니다
그리고 리소스 소유자 혹은 엔드 유저가
이 웹 애플리케이션에 대해 많은 신뢰를 가지게 되었을 것입니다
본인의 인증서를 제 웹사이트 즉, TweetAnalyzer와
공유할 필요가 없기 때문이죠
대신, 그는 그의 세부 정보들을
트위터 로그인 페이지에 작성하고 있는 것입니다
세 번째 단계에서는, 리소스 소유자가
본인의 인증서를 직접 트위터의 로그인 페이지에 작성합니다
성공적인 인증 이후에
트위터 애플리케이션은 허가 페이지를 보여줄 것입니다
유저에게 트윗 데이터를 공유해도 되는지 허락을 구합니다
이것은 '읽기 모드'로 클라이언트 즉, TweetAnalyzer 에게
전달되며 간단한 세부 사항만 보여줍니다
그것을 본다면
저는 TweetAnalyzer를 분명히
사용하고 싶기 때문에
허가 페이지에 '승인'이라고 작성할 것입니다
트위터 애플리케이션 속 승인 서버의
허가요청에 응하고 나면
네 번째 단계에서는, 승인 서버가
액세스 토큰과 리프레쉬 토큰을 발급합니다
클라이언트 애플리케이션에게 말이죠
우리는 이제 리프레쉬 토큰이 무엇인지 그리고
액세스 토큰이 무엇인지에 대해 이야기를 나누겠습니다
하지만 지금 명심해야 할 것은
액세스 토큰을 사용하면
클라이언트 애플리케이션이 리소스 서버에 의해 관리되는
REST APIs를 실행시키고
정확한 답변을 받을 수 있도록 한다는 것입니다
따라서 이 액세스 토큰과 리프레쉬 토큰은
무작위로 작동되는 복잡한 스트링이며
추측하는 데 어려움이 있습니다
따라서 클라이언트에게도 토큰을 어떻게 보관할지에 대한
선택지가 있습니다
왜냐하면 승인 서버는 이 토큰들을
24시간 혹은 7일의 유효 기간을
지닌 상태로 발급하기 때문입니다
따라서 이는 승인 서버에게 달려있다고 볼 수 있습니다
유효기간과 어떤 것을 설정하고 싶은지 등을 말이죠
만약 클라이언트 애플리케이션이 이러한 세부 사항을 보관하면
엔드 유저나 리소스 소유자에게 인증서 입력을
트위터 로그인 페이지에서
계속 반복적으로 요청할 필요가 없습니다
따라서 이것이 승인서버로부터 부여받은
토큰을 잘 보관해야 하는 이유입니다
클라이언트 애플리케이션에게
5가지 단계를 통해 액세스 토큰과 신규 토큰을 부여받았다면
TweetAnalyzer 웹사이트가
트위터의 리소스 소유자에게 요청을 보냅니다
/getTweets라는 API를 실행하여 말이죠
하지만 리소스 서버에서
API를 실행시키려고 할 때마다
승인 서버에서 받은 액세스 토큰을
넘겨주어야 합니다
클라이언트 애플리케이션이 이 세부 사항을 모두 보내자마자
리소스 서버는 Auth 서버와 액세스 토큰을 확인합니다
왜냐하면 이 둘은 모두 같은 단체에
속해있기 때문입니다
이 시나리오 상에서는 트위터겠죠
만약 액세스 토큰이 적절하다면 TweetAnalyzer만
트윗 정보를 가지게 될 것입니다
따라서, 제 3의 웹 애플리케이션은
매우 제한된 접근성을 가지게 되는 것이죠
트윗에 대한 정보를 오직 읽기만 할 수 있는 것입니다
새로운 트윗을 쓸 수 없으며, 프로필을 업데이트할 수 없고
이메일이나 비밀번호를 수정할 수 없습니다
이것이 액세스 토큰의 장점입니다
그리고 이 Oauth2 구조물의 장점이기도 하죠
마지막 단계에서는, 예상할 수 있듯이
클라이언트 애플리케이션이 모든 트윗을 전달받습니다
뒤에서 비즈니스 로직을 실행하고
레포트를 엔드 유저이자 리소스 소유자에게 전달합니다
엔드 유저는 레포트를 확인하고 매우 기뻐합니다
Oauth2 구조물 덕에 자신의 트위터 인증서를 공유하지 않고
이러한 결과물을 얻을 수 있었기 때문에
기쁜 것이죠
이것은 상상하실 수 있을 만한 Oauth2 플로우의 샘플입니다
이해가 안 가시는 부분이 없길 바랍니다
다음 수업에서는
단순한 예시를 가지고
우리가 지금까지 이야기를 나누었던 플로우에 대한
데모들을 살펴보도록 합시다
감사하고, 다음 강의에서 뵙겠습니다
수고하셨습니다