WEB2 - OAuth 2.0 (1)

---

https://opentutorials.org/module/3668

WEB2 - OAuth 2.0

https://www.youtube.com/playlist?list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-

WEB2-OAuth

 

---

OAuth는 더 큰 세상으로 통하는 관문입니다.

OAuth를 이용해서 다른 서비스에 접근할 수 있는 권한을 획득할 수 있거든요.

 

반대로 다른 서비스에게 권한을 부여할수도 있습니다.

 

이 수업에서는 OAuth의 원리에 대해서 알려드립니다.

 

===

1.수업소개

OAuth2는 여러가지 애플리케이션 기술들(=Python, Java...)을 이용해서 구현되는 기술

▽맞지 웹서버와 WAS의 차이 테코톡에서 볼 때 웹 어플리케이션 서버가 뭔지 배웠지

 

이 기술과 관련해서 3개의 참여자가 등장함

(1)

나의 서비스, 예를 들어 opentutorials.org

(2)

이 서비스를 사용하는 사용자

(3)

나의 서비스가 연동하려고 하는 그들의 서비스(Google, Facebook..)

 

사용자가 우리 서비스에 접속해서 글을 쓰면

->나의 서비스가 사용자를 대신해서 구글과 같은 서비스의 Calendar에다가 날짜를 기록한다든지 Facebook에다가 글을 썼다라는걸 공유해준다든지 이런것들을 하고 싶다

 

그러기 위해선 우리가 사용자로부터 사용자가 사용하고 있는 그들의 서비스에 접근할 수 있도록 허가를 받아야해

가장 쉬운 방법은 그들의 서비스에 사용자의 ID, Password를 사용자로부터 전달받아서 우리가 그걸 기억하고 있다가,

그들의 서비스에 접속할 때 그 ID, Password를 이용하는 것. 아주 간단하고 그들의 서비스의 모든 기능을 다 사용가능

 

하지만 상당히 위험하고 걱정되는 방법

->

사용자 입장에선 자신의 구글, 페이스북과 같은 서비스의 ID, password를 처음보는 서비스한테 맡겨야한다

사용자한텐 사용자의 모든 사이트의 ID, Password가 같을 수도 있어서 큰일날 수 있어

우리한테도 좋은 일이 아님. 내가 갖고있다가 유실되면?

Google, facebook입장에서도 자신의 사용자의 ID, password를 신뢰할 수 없는 제3자가 갖고있는건 불만족

 

 

이런 상황에서 우리를 구원해줄 도구가 OAuth

훨씬 더 안전하게 우리가 만든 서비스를 그들의 서비스와 상호작용 할 수 있게 된다.

유저의 요청에 의해 그들의 서비스가 ID, Password대신에 accessToken이라고 하는 일종의 비밀번호를 발급함.

 

 

accessToken : 

(1)ID, password가 아니다

(2)그들의 서비스가 갖고 있는 모든 기능이 아니라 그중에 나의 서비스가 꼭 필요한 필수적인 기능만 부분적으로 허용하는 비밀번호다

 

그들의 서비스의 accessToken을 우리가 OAuth를 통해서 획득한 다음에

그 accessToken을 통해서 그들의 서비스에 접근해서 

데이터를 가져오고 수정하고 생성하고 삭제하는 작업을 할 수 있게 된다

 

 

OAuth의 이런 특징을 이용하면, 아예 회원들의 ID, password를 처음부터 보관하지 않고, 회원을 식별할 수 있는 기능을 구현할 수 있다

이런것의 가장 기반에 있는 기술이 OAuth

 

지금부터 우리는 OAuth를 이용해서 accessToken을 얻어내는 원리를 탐험할 것

이 수업에선 구현방법을 소개하지는 못해, OAuth라는 복잡한 시스템이 동작하는 핵심원리를 파악할 수 있게됨

 

===

2.역할

OAuth같은 추상적인 개념을 맞닥뜨리면 용어가 문제다

OAuth에서 등장하는 3개의 주체를 뭐라고 부르는지 용어 학습

 

이전 시간에선 

(1)우리의 서비스

(2)사용자

(3)사용자가 가입해있는 그들의 서비스

세개 였는데

 

(3)Resource Server

 : 우리가 제어하고자 하는 자원을 갖고 있는 서버 구글

(2)Resource Owner

 : 자원의 소유자 라고 하네 리소스 오너가 자원을 갖고 있는 서버(구글)가 아니고 서비스 사용자야 Owner

(1)Client

 : 리소스 서버에 접속해서 정보를 가져가는 클라이언트라는 뜻에서 => 클라이언트가 나구나??

 

이 셋의 관계가 OAuth의 핵심

 

OAuth의 공식메뉴얼을 보면 Authorization Server라고 하는게 하나 더 있는데, 

Resource Server는 데이터를 갖고 있는 서버

Authorization Server는 인증과 관련된 처리를 전담하는 서버, 공식메뉴얼에서는 이 두개를 구분한다

 

우리는 그냥 두개를 합쳐 부른다  ▽둘다 페이스북, 구글이라는거 아녀~

 

===

3.등록

 

OAuth를 등록하는 절차 중 첫번째는 등록

우리의 상황은 서버, 오너, 클라이언트가 있다

 

Client가 Resource Server를 이용하기 위해선 RS의 승인을 사전에 받아놔야 한다, 그걸 register, 등록이라고 함

서비스마다 등록하는 방법이 다르지만, 공통적인 것은

이 세가지 값을 가짐

Client ID : 우리가 만들고 있는 어플리케이션 식별하는 식별자

Client Secret : 그것에 대한 비밀번호

ID는 외부에 노출될 수 있지만, Secret은 안된다

Authorized redirect URIs : 권한을 부여하다, RS가 권한을 부여하는 과정에서 우리에게 Authorized Code라고 하는 값을 전달해주는데, 이 주소로 전달해주세요 라고 알려주는 것,

RS는 저 주소말고 다른걸로 요청하면 무시함  ▽요청할 때 저걸 적어내거든 다다음 강의보면

 

---

예로 현실에서의 OAuth 시스템들은 어떻게 등록과정을 거치는지 볼 것

 

developers.facebook.com은 페이스북의 개발자 페이지

이런게 있어

Display Name만 쓰고 Create App ID누르면

이런 화면이 뜨고

Facebook Login을 Set Up 하면

Web을 클릭

쓰는거 끝내고

Settings로

이게 아까 그건데 주소를 입력하고 저장함

 

그 다음 Settings의 Basic에 보면

ID

App Secret

 

값이 있다

 

===

구글의 경우는 Cloud Platform이라는 곳에서 

구글에선 Project라고 부름

CREATE누르면 프로젝트가 생성이 됨

 

우리가 하려는게 API를 제어하려는 거니까 API & Services를 누르면

제어할 자격을 얻어야해서 Credentials(자격)

 

저 파란 버튼을 누르면 반가운 OAuth client ID 가 뜸

그거 하기전에 뭘 좀 하라고 뜨는데 Configure consent screen : 사용자가 인증하는 과정에서 보여지는 화면을 세팅해 줘

저기다 우리 프로젝트 이름을 적고, Privacy는 꼭 적으라고 돼 있지만 개발할 때는 괜찮대, Save

 

애플리케이션 타입을 저는 웹으로 정하고

이름은 그냥 그거

밑에 Authorized redirect URIs가 여기도 있네요

 

넘어가면

ID와 secret을 보여줌, 잊어버리면 안됩니다

 

구글과 페이스북에서 실제로 어떻게 클라이언트를 등록하는가를 살펴봄

OAuth를 통해서 제어할 수 있는 대상은 많지만 예를 든 것

 

===

4.Resource Owner의 승인

 

인증을 받는 과정을 살펴봅니다 꽤 깊은 레벨까지

[1]

등록을 하게되면 RS와 Client는 양쪽 다 

Client id

Client Secret

redirect URL

을 안다

Client는 redirect URL에 해당하는 페이지를 구현하고 기다리고 있어야 한다

RS에 A,B,C,D라는 기능이 있다면, Client는 B, C의 기능만 필요하다면 모든 기능에 대해서 인증을 받는게 아니라 최소한의 기능에대해서만 인증을 받는게 훨씬 더 서로에게 좋다

 

(1)RO는 우리의 어플리케이션에 접속함. 그러다 우리가 RS를 사용해야하는 상황이 있다, 페이스북에 글을 쓰거나 구글캘린더에 날짜를 기록하거나..

(2)그때 나는

이런 화면을 보여주거나, 인증을 거쳐야 합니다 라는 메시지를 띄울 것, 뭐든간에 사용자가 동의(=버튼을 클릭하는게 동의한다는 뜻)해야 그 다음 과정으로 진행함

(3)그 버튼은 별거 아니다

이렇게 생긴 링크를 만들어주면 된다

resource.server

client_id

scope : 우리가 사용하려는 기능

redirect_uri

얘네를 주소로 링크로 제공을 해주면 됨

 

예를 들면

이 링크의 주소는

저 사이트에서 Decode를 누르면 사람이 보기 좋은 형태로 바꿔줌

redirect_url

scope이 구글이 정해놓은 형식에 따라 정보가 들어가 있어

client_id

가 있다

 

RO가 저 주소로 접속을 하게되면

RS가, RO가 현재 로그인이 돼 있는지 아닌지를 봐서 

로그인이 안돼있으면 로그인을 하라는 화면을 보여줌

로그인을 해서 성공했다면 RS는 그때서야 주소에 있는 client_id값과 같은 client id값이 있는지

그리고 자신이 갖고있는 Client id 1인 redirect URL이 저건데 

접속을 시도하고자 하는 요청의 redirect_uri값과 같은지 다른지 확인해서

다르면 컷

같으면 RO에게 scope에 해당되는 권한을 Client에게 부여할건지 확인하는 메시지를 전송하게됨

어떠어떤것을 어떤 Client가 요청하고 있다. 허용?

 

허용버튼을 누르면 허용했다는 정보가 RS로 전송됨

RS는 이제 

▽Client id / Client Secret / redirect URL과 함께

'(RO의 user id가 1번 일 때) user id 1번은 scope b와 c에 대한 작업을 허용하는것에 동의했다'

는 정보를 서버에다 저장함 DB일수도 있고 파일일수도 있고..

 

이렇게 사용자로부터 RS에 접속하는것에 대한 동의를 구하는 과정을 거침

 

그럼이제 RS가 실제로 인증을 어떻게 처리하는지 다음시간에