개념
Google, Facebook, Twitter...같은 서비스로부터 Access Token을 받아서 접근 권한을 얻게 해준다.
접근 권한의 범위는 조절 가능하다.
웹 사이트에서 보는 다음 로그인 화면이 OAuth를 이용하여 구현된 기능이다.
용어
- Resource Server
- 이용 하고자 하는 서비스(Google, Facebook, Twitter)
- 리소스 관련 데이터 전담
- Authorization Server
- 이용 하고자 하는 서비스(Google, Facebook, Twitter)
- 인증과 관련 데이터 전담
- Resource Owner
- 사용자
- Client
- 내가 만든 서비스
- OAuth를 이용하여 Resource, Authorization Server로 부터 서비스를 사용하고자 한다.
- Resource Server 와 Authorization Server를 구분하지 않고 Resource Server라고 지칭하기도 한다.
과정
1. Client 등록 과정
Resource Server의 OAuth를 사용하기 위해 Client를 Resource Server에 등록할 필요가 있다.
등록을 하는 방법은 Resource Server(Google, Facebook, Twitter...)마다 다르다
대부분 다으모가 같은 작업을 거친다.
- Resource Server 접속
- Resource Server에서 Create App or Create Project 수행
- Authorized redirect URIs 등록. 여기에는 Client의 URI가 들어간다.
- Resource Server에 생성된 App이나 Project를 통해 Create ID, Client Secret 생성. Client Secret은 노출되면 안된다.
여기까지 완료되면 Client와 Resource Server는 둘다 Create ID, Client Secret, redirect uri를 알게 된다.
2. Resource Owner의 인증
- Resrouce Onwer(사용자)가 Client(내가 만든 서비스)를 기능을 이용하기 위해 접속
- 기능을 이용하기 위해서는 Resource Server의 B, C 권한 필요
- Client는 Resrouce Onwer에게 동의를 구하는 UI 제공
- 그림과 같이 Login 버튼이나 다른 페이지를 사용자에게 제공할 수 있다.
- Resrouce Onwer에게 보여지는 버튼 Resource Server URL(client_id(ID), scope(권한 범위), redirect_uri 정보가 같이 있음)과 링크되어 있다.
EX) URI
- Resource Onwer의 Resource Server 로그인
- Resource Onwer가 버튼을 누를 경우 Resource Server URL로 접속을 하며 만약 Resource Onwer가 Resource Server에 로그인 되어 있지 않으면 Rersource Server는 위와 같은 로그인 화면을 보여준다.
- Resource Onwer가 로그인을 성공하면 Resource Server는 넘겨받은 URL에서 client_id와 redirect_uri를 가져온다. client_id로 레코드를 찾으며 찾은 레코드의 redirect uri와 넘겨 받은 파라미터의 redirect_uri가 일치하는지 검증한다. 일치하지 않으면 프로세스를 진행하지 않는다
- redirect uri까지 검증이 완료되면 Resource Server는 Resource Owner에게 scope에 명시된 권한을 허용한다고 알리는 페이지를 Resource Ownwer에게 보여준다.
3. Resource Server의 승인
- Resource Ownwer가 허용을 하면 허용을 하였다는 정보가 Resource Server에 저장이 된다.
- user id : 1, scope : b, c
- Resource Server는 Redirect URL을 응답으로 Resource Owner에 전달
- Redirect URL에는 authorization code(임시 비밀 번호)가 포함되어 있다.
- Resource Owner는 Redirect URL로 다시 접속
- Client는 authorization code를 이용해서 다시 Resource Server에 접근
- URL에는 grant_type, redirect_uri, client_id, client_secret 정보가 같이 들어 있음
- 전달 받은 Resource Server는 자신이 가지고 있는 redirect_uri, client_id, client_secret, authorization code가 모두 일치 하는지 검증을 한다.
4. 액세스 토큰 발급
- 액세스 토큰이 Client에게 발급 된다.
- 액세스 토큰은 user id에 해당하는 사용자에 대해 b, c 권한을 사용할 수 있다는 의미를 담는다.
5. 액세스 토큰 사용
- 액세스 토큰을 얻었다면 Resource Server(Google, Facebook, Twitter...)의 API를 사용할 수 있다는 뜻이다.
EX) Google 캘린더 API
- 액세스 토큰을 파라미터로 기입 할 수 있는 API를 제공한다
6. 리프레쉬 토큰 사용
- 액세스 토큰이 만료되면 리프레쉬 토큰을 이용하여 갱신 가능하다
정리
- OAuth를 사용하여 다른 서비스를 통해 사용자를 인증 할 수도 있지만 궁극적인 목적은 다른 서비스의 API를 사용하기 위해서다
mohadang