강의: https://opentutorials.org/course/3405
OAuth가 필요한 이유
아래 그림으로 설명하면 사용자가 mine(opentutorials.org)의 서비스를 사용하려고 할 때, ID와 Password를 통해 접속하려고 합니다. 이때 mine은 Their(e.g., Google, Facebook)에게 ID, Password를 통해 접속을 시도하도록 합니다. 이 경우 사용자는 ID, Password를 mine, Their 두 주체가 알고 있는 것에 대해 보안상 신뢰를 얻지 못할 수 있습니다. 두 주체 역시 유출 등의 문제를 원하지 않습니다.
따라서 아래 그림처럼 accessToken이라는 일종의 암호를 통해 소통하는 것이 좋습니다. 이를 활용하면 Their의 모든 서비스 접근이 아닌 특정 서비스만 접근할 수 있도록 해주기도 합니다. 보안상의 이점이 있는 것입니다. 이를 가능하게 해주는 것이 OAuth입니다.
용어
앞서 세 가지 주체에 대한 용어부터 정리합니다.
Their: Resource Server입니다. 자원을 가지고 있는 서버입니다.
User: Resource Owner입니다. 자원의 소유자입니다.
mine: Client입니다. 리소스 서버에 접근해서 데이터를 활용하는 주체입니다.
그런데 여기서 한 가지 주체가 더 추가됩니다.
Authorization Server는 인증과 관련된 처리를 담당하는 서버입니다. 공식 문서상 두 가지를 구분하지만 이 내용에는 두 가지를 합쳐서 Resource Server로 표현합니다.
등록
Resource Server의 데이터를 이용하려면 먼저 등록 과정을 거쳐야 합니다.(영상에 Facebook 예시가 나옵니다.) 등록 과정에서 Client 서비스를 등록합니다.
이때 Client의 ID와 Secret, Authorized redirect URls가 생성됩니다.
Resource Owner의 승인
등록 후 Resource Server와 Client는 Client id, Client Secret, redirect URL을 알고 있는 상황입니다. 아래 A, B, C, D는 Resource Server가 제공하는 기능들인데, 이중에서 필요한 기능만 선택이 가능합니다.
Resource Owner, 즉 사용자는 Client의 서비스를 사용하려고 접근하려 할 것입니다. 접속을 의미합니다. 그리고 Resource Server의 서비스를 사용하게 되는 상황이 됩니다. 예를 들어 Facebook의 포스트와 같은 것입니다. 이때 Client는 아래처럼 로그인 화면을 Resource Owner에게 보여줍니다. 그리고 Facebook의 특정 기능을 사용하려면 인증이 필요함을 알려줄 것입니다. 아래 이미지의 로그인 버튼을 누르면 동의하겠다는 의미입니다. 중간에 링크를 만들어주는 것을 통해 버튼을 구현합니다. 링크를 보면 resource.server 이후 client_id, scope=B,C(선택 기능), redirect_url이 포함되어 있음을 알 수 있습니다.
만약 여기서 Resource Owner가 Resource Server에 로그인되어있지 않다면, 로그인 화면을 보여줄 것입니다. 로그인 후 Resource Server는 그때서야 아래 링크에서 보이는 client_id와 일치하는 Client id가 있는지 확인하고 redirect URL도 일치하는지 확인합니다.
이후 Resource Server는 Resource Owner에게 어떤 Client가 특정 기능에 요청하고 있는데, 허용할 것인지를 묻습니다.
허용하면 아래처럼 Resource Server는 user id:1, scope: b, c를 갖게됩니다. 의미는 user id:1이 b, c 기능에 대한 허용을 했다는 의미입니다.
Resource Server의 승인
지금까지 Resource Owner의 승인이 마쳐진 상태입니다. 이제 Resource Server의 승인이 필요합니다. Resource Server는 authorization code: 3이라는 임시 비밀번호를 생성하고 Resource Owner에게 넘겨줍니다. 이때 redirection하라는 명령도 생기는데, 화살표 위에 Location으로 이동하도록 하는 명령이며 Resource Owner의 웹 브라우저에게 내려지는 명령입니다.
해당 헤더를 갖는 링크로 이동한다는 것은 Client가 authorization code: 3을 알게 된다는 것입니다.
그리고 Client는 Resource Server에 직접 접속합니다. 화살표 링크를 보면 authorization code, redirect_url, client_id, client_secret 모두를 포함하고 있습니다. Client는 authorization code와 client_secret 두 가지 비밀정보를 결합해 Resource Server에게 전달하고, Resource Server는 authorization code를 보고 그 code에 해당하는 정보와 일치하는지 확인합니다. authorization code, redirect URL, Client id, Client Secret 모두가 일치한다면 다음 단계로 넘어갑니다.
Access Token 발급
authorization code를 통해 인증을 마친 상황입니다. authorization code는 인증에 사용되었고 더이상 필요하지 않으니 지워집니다. 이때 Resource Server는 access Token을 발급합니다. Client에게 accessToken 값을 응답해 Client는 accessToken을 알게됩니다. Client가 acessToken이 4라는 것을 통해 Resource Server에 접근하면, Resource Server는 accessToken을 보고 그 accessToken을 갖고 있는 사용자에게 허용하게 됩니다.
API 호출
궁극적으로 Client는 Resource Server가 가진 어떤 기능을 사용하는 것입니다. 이를 가능하게 해주는 것이 API(Application Programming Interface)입니다. Resource Server(영상의 예시는 구글 캘린더)는 특정 API를 사용하는 것에 대한 설명을 문서로 가지고 있을 것입니다.
Refresh Token
Access Token은 수명이 있습니다. 수명이 끝나면 API에 접속했을 때 API가 데이터를 주지 않습니다. 다시 발급받아야 할 때 사용되는 것이 Refresh Token입니다. 보통 Access Token이 발급될 때 Refresh Token이 동시에 발급됩니다. Access Token이 만료되면 가지고 있었던 Refresh Token을 Resource Server에게 넘겨주고 다시 Access Token을 받게됩니다.
요약
1. 개발자 입장
Client가 어떤 서비스를 제공하려고 할 때 기능을 가지고 있는 Resource Server(예를 들어 Facebook 등)의 해당 기능을 이용하려는 것입니다. 이를 통해 Client는 사용자인 Resource Owner가 API를 사용할 수 있도록 합니다.
그 API를 이용하려면 먼저 Resource Sever로 등록이 필요합니다. 등록을 통해서 Client는 Client ID와 Client Secret을 받게 됩니다. 동시에 redirect URL도 받습니다.
2. 사용자 입장
앞서 내용을 남긴 개발자 입장은 사용자 입장에서 신경쓰지 않습니다. 개발자 입장은 단지 서비스를 제공하기 위해서 다른 누군가의 API를 사용할 것이고, 이를 위해서 등록을 했을 뿐입니다.
먼저 누군가가 Client가 제공하는 서비스를 이용하고 싶어한다고 가정하겠습니다. Client는 서비스 이용을 위해 Client에 접속하려고 하는데, 이와 같은 움직임이 발생하면 사용자는 선택권을 갖게 됩니다. 만약 사용자가 Resource Server에 로그인되어있지 않다면, 로그인을 요구한 후 사용자가 이용하려는 Client의 서비스가 Resource Server에서 제공하는 기능에 접근하려고함을 알려줍니다. 이때 사용자가 수락하면 사용자는 결국 Resource Server에 있는 API를 Client를 통해 사용하겠다는 의미가 됩니다.
3. Resource Server 입장
앞서 개발자 입장에 내용을 적지는 않았지만, 개발자나 Resource Server는 모두 사용자의 정보에 대한 보안에 신경쓰려합니다. Resource Server는 마지막에 Access Token을 발급할 것인데, 이 Access Token이 OAuth의 핵심임을 알고 있습니다. 사용자의 ID와 Password를 직접 다루지 않게 해서 보안에 신경쓴다는 의미입니다.
다시 돌아와서 순서대로 살펴보면, 사용자는 궁극적으로 Resource Server의 API를 사용하려는 것이고 그렇게 하기까지 보안에 신경쓴 움직임이 이뤄져야 합니다. 먼저 Resource Server는 Authorization Code라는 임시 비밀번호를 생성하고 사용자의 웹 브라우저에게 Redirection할 것을 명령합니다. Authorization Code를 갖고 Client에게 다시 연결하면, Client는 Resource Server에게 직접 접속을 시도합니다.
Resource Server는 지금까지 움직임에서 많은 정보를 알고 있습니다. Client로부터 넘겨받은 Authorization Code, Client Secret 두 가지를 가지고 자신이 갖고 있었던 것과 일치하는지 확인합니다. Authorization Code, Redirect URL, Cliend ID, Client Secret 모두가 일치하면 다음 단계로 넘어갑니다.
여기서 잠깐 Authorization Code의 흐름을 다시 살펴보면 아래와 같습니다.
- Authorization Code는 Resource Server로부터 생성되어 사용자에게 전달합니다.
- 동시에 Resource Server는 사용자의 웹 브라우저에게 Authorization Code를 갖고 Redirection할 것을 명령합니다.
- Client는 웹 브라우저로부터 받은 Authorization Code를 갖고 Resource Server에 접근합니다.
- 마지막으로 Resource Server는 그동안 전달되었던 정보를 가지고 일치하는지 여부를 판단합니다.
Authorization Code의 사용은 끝나고 이제 소멸됩니다. 그리고 Resource Server는 Client에게 Access Token을 보내 Access Token을 가지고 있는 사용자가 API를 이용할 수 있도록 허용합니다.
