https://www.youtube.com/watch?v=UH5XnjkBqKE&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=4
위 영상을 시청한 뒤 작성한 글입니다.
WEB2 - OAuth 2.0 : 4. Resource Owner의 승인
앞서서까지는 등록과정을 살펴봤고, 지금부터는 인증을 받는 과정을 제시한다.
우리가 등록을 하게 되면, Resource Server와 Client는 공통적으로 Client id, Client Secret, redirect URL 3가지 정보를 알게 된다.
Client는 redirect URL에 해당하는 화면을 구현 완료한 뒤 승인을 기다리고 있어야한다.
위 그림처럼 Resource Server가 가지고 있는 기능이 A,B,C,D로 4개라고 하자. 이때, Client가 B,C에 해당하는 2개의 기능만 필요하다면, 모든 기능에 대한 인증이 X라 최소한의 기능에 대해서만 인증을 받는 것이 서로에게 좋다.
이때 각 주체들에서 발생하는 일은 다음과 같다.
1. Resource Owner
: Client 즉 application에 접속을 한다.
2. Client
: Resouece Owner가 Resource Server가 필요한 일을 수행하고자 원한다면, 위 그림과 같이 로그인 화면 등을 보여주게 될 것이다. (ex. 구글 캘린더에 접속하기)
2-1. 사용자 동의 의미하는 로그인 버튼 만들기
순서대로 client_id의 값, scope(내가 사용하고자 하는 기능들, redirect_url를 의미한다.
3. Resource Owner의 접속
: Resource Owner가 Resource server로 접속을 redirect_url 주소로 한다.
그러면, Resource Server가 해당 Resource Owner가 현재 로그인되어 있는지 여부를 확인하고 각기 다른 화면을 보여준다.
3.1 Resource Owner가 로그인 되어 있지 않은 경우
로그인이 되어 있지 않는다면, 로그인을 하라는 화면을 보여준다.
3.2 Resource Owner가 로그인 되어 있는 경우
(1) Resource Server가 가지고 있는 Client id 값들 중 요청이 들어온 client id 값이 있는지를 확인한다.
(2) 일치하는 Client id 값이 있다면 요청이 들어온 redirect_uri 와 자신이 가지고 있는 redirect URL이 일치하는지를 확인한다.
확인 결과에 따라 다음과 같이 Resource Server는 작동한다.
(1) 일치하지 않는다면, 바로 작업을 종료한다.
(2) 일치한다면, Resource Owner에게 해당 scope에 해당되는 권한을 Client에게 부여할 것인지를 확인하는 메세지를 전송한다.
위 그림에서 나타나는 허용 메세지에 Resource Owner가 허용 버튼을 누르면, 허용을 했다는 정보가 Resource Server로 넘어간다.
user id가 1이라고 했을때, (허용 버튼을 누른 Resource Owner의 id가 1이라고 가정시) user id 1번이 scope b,c를 허용했다는 정보를 Resource Server가 저장하게 되는 것이다.
