생활코딩에 설명이 잘 되어있었다.
하지만 더 쉽게 설명해보려고 한다.
OAuth의 목적은 서비스의 연동이다.
연동의 목적은 해당 서비스를 이용하기 위함이다.
해당 서비스를 직접 이용하면 되는 것 아니냐고??
당연히 편의성을 위한 기능이다.
하지만 편의성만 챙기면 안되는 것처럼 보안성을 올리기 위한 방법이다.
가장 대표적인 것이 소셜로그인이라고 할 수 있다.
알아보자
OAuth는 3가지가 있다.
1. 내가 만든 서비스 (mine)
2. 서비스를 쓰는 사람 (User)
3. 서비스를 쓰는 사람이 가입된 다른 서비스(Their)
앞서 말했다시피 1과 3의 연동을 한 작업을 2에게 제공하는 것이 목표다.
하지만 위에 것을 일반적으로 설명할 때고
제일 중요한 자원 중심으로 얘기를 할 때는 다르게 말한다.
이름만 달라졌다.
추가된 것이 하나가 있다. Authorization Server가 추가되었다. 뭐 특별한 것은 아니다.
** 공식 문서에서는 Resource 관리와 Authorization 관리를 다르게 한다.
변경된 이름으로 다시 설명해보자면
1. Client => Resource Owner의 Resource를 확보하려고 하는 나의 서비스
2. Resource Owner => Resource를 권한을 가지고 있는 주체
3. Resource Server => Resource를 관리하는 서버
**User입장에서 나의 서비스는 서버였지만 OAuth에서는 Client가 된다.
동작을 하나씩 알아보자
1. Register
Client는 Resource가 필요하다고 했다.
하지만 Resource Server를 이용할 권한이 없다.
그래서 등록(register)해주어야 한다.
등록하는 방법은 다 다르지만
대부분 공통적으로 아래 3가지를 Resource Server에서 요구한다.
Client ID => 클라이언트를 구분하는 속성
Secret => 비밀번호라고 생각하면 된다.
Authorized redirect URIs => Resource Server가 Client에게 Authorized Code 를 전달할 것인데
Client에서 어디로 받느냐? 라는 것을 정의한 것이다.
다시 말해서 인증과정이 끝나면 다시 나의 서비스로 돌아와야 하는데 어떻게 돌아오냐? 의 길을 알려준다고 생각하면 된다.
**즉, 클라이언트가 Response를 어디로 받느냐다.
2. Authorize
등록을 했다면 Resource를 제공하는 인증과정은 어떻게 될까?
우선 등록 후에는 갖고 있는 정보가 달라진다.
클라이언트와 서버는 이러한 정보를 가지게 된다.
그리고 Resource 에 대해서 여러가지가 있다고 했을 때
클라이언트가 필요한 것을 B,C라고 해보자.
굳이 A와 D에 대한 권한을 줄 필요는 없다.
그렇다면 돌아가보자
Resource Owner는 Client에게 서비스를 요청한다. (Server지만 여기서는 Client)
그렇게 될 때 Client는 사용자의 Resource를 사용하기 위해 인증과정이 필요하다.
가장 먼저 이것을 확인한다.
해당 요청을 Resource Server가 받는다면 클라이언트가 등록되어있는지? 확인
redirect_uri 가 일치하는지? 확인
즉, 여러가지 절차를 거쳐서 저 클라이언트가 요구한 것인지 확인하는 작업이다.
만약 redirect가 다르다면..? 제 3자가 조작한 요청일 수도 있다.
**꼭 그렇다는 것은 아니고 그럴 수도 있다는 이야기다.
그렇게 등록된 클라이언트라면 이제 Resource Owner의 승인을 받아야 한다.
우선 Resource Owner가 Resource Server에 등록되어 있는지? 확인한다.
등록되어 있다면 로그인을 하면 된다.
로그인이 성공하면
해당 클라이언트에서
몇몇 권한에 대해 승인을 해달라고 요구를 하고 있다.
Owner가 원한다면 승인해달라라는 창이다.
허용을 한다면 Resource Server에서는 Owner가 승인을 했다고 정보를 받게 된다.
그렇다면 Resource Server 가 가지고 있는 정보가 수정된다.
client id: 1인 클라이언트에게
user id 1인 유저는 b,c 권한을 허용했다. 라는 것이다.
이것은 Resource Owner가 승인한 것이다.
그렇다면 이제 앞서 말한 Resource Server에서 Authorize는 어떻게 될까?
즉, Access Token을 어떻게 받게 되는걸까?
우선 앞서 승인을 받게 되면 Resource Server는 Resource Owner에게 Authorization code를 준다.
웹사이트를 예로 들면 승인 버튼을 눌렀다면 Redirect 됨과 동시에 code를 받아온다.
즉, Resource Owner는 Code와 함께 클라이언트의 redirect_uri 에 연결된다.
그렇게 되면 Resource Owner가 받은 Authorization code를 이제 Client도 알게 된다.
그렇게 되면 Resource Owner가 받은 코드를 이용하여 Resource Server에 접근이 가능해진다.
예를 들면 위와 같이 Resource Server에게 token을 요청하면서 관련된 데이터들을 같이 전달해준다.
**특히 Client Secret 값을 전송하게 된다.
이 때 날것으로 전달하는 것이 아니라 처리를 거쳐서 전달되게 된다.
Resource Server는 받은 값을 갖고 있는 값과 비교하여 같다면
이제 Access Token을 발급할 수 있는 단계까지 왔다.
Resource Owner의 승인으로 Code를 받고 그 Code를 클라이언트가 요청하는데 썼다.
Authorize Code는 이제 필요가 없다.
즉, 다시 Resoure Owner가 다시 code를 전달할 필요가 없다.
이제는 AccessToken을 이용하여 할 것이기 때문이다.
클라이언트는 이제 Resource Owner가 가진 Resource를 사용할 때 AccessToken을 이용하면 된다.
AccessToken에는 Resource Owner의 정보가 들어있다.
다시 말하면 저 AccessToken을 이용하면 그 Resource Owner의 조작과 같다는 이야기다.
이제는 그 AccessToken으로 API를 이용하면 되겠다.
마지막으로 RefreshToken만 하면 끝이다.
AccessToken은 Resource Server에서 vaild한 시간이 있다.
즉, 그 AccessToken으로는 API를 이용할 수 없게 된다. 그래서 다시 갱신해야 한다.
그것이 바로 RefreshToken 이다.
처음부터 위의 모든 과정을 해야하는 것은 아니고 조금 더 간소화된 과정으로 가능하다.
간단하게 그림을 보면 이렇다.
**그림에서 Resource Server와 Authorization을 구분하고 있다.
B를 보면 Refresh Token도 응답으로 받음을 알 수 있다.
이 Refresh Token은 Invalid Token Error가 뜰 때 사용하는 것이다.
그렇게 되면 Refresh Token을 보냄으로써 다시 AccessToken을 재발급 받는 것이다.
** 하지만 Refresh 하는 방법은 다 다르다.
이런 것이 있다만 알아두고 자세한 것은 각 플랫폼을 보면 되겠다.
요약
1. 우선 내 서비스를 제 3 서비스에 등록한다. (등록은 당연히 되어있다고 생각하고 생략해도 됨)
2. Resource Owner가 내 서비스에게 요청한다.
3. 내 서비스는 제 3 서비스에게 요청한다.
4. 제 3서비스는 내가 등록되었다면 Resource Owner에게 로그인을 요청한다.
5. Resource Owner의 인증을 위해 내 서비스는 Resource Owner에게 로그인과 같은 것을 요청한다.
6. Redirect가 되면서 Client에게 Authorize Code를 넘겨받는다.
7. 해당 Authorize Code를 이용하여 AccessToken을 요청한다.
8. 체크 후 내 서비스는 AccessToken을 갖게 된다.
9. 사용자는 이제 AccessToken 을 이용하여 내 서비스를 이용할 수 있다.
아래 이미지도 유용하게 사용할 수 있을 것 같다.
아래의 2~6는 위에서 내가 설명한 2~8와 같음
**참고로 소셜로그인 같이
내가 처음 보는 웹사이트도 구글로그인이 가능한 이유는
구글에서 우리를 보장하기 때문이다.
참고링크
'CS Interview' 카테고리의 다른 글
| 개발자 취업 준비 자료, 개발자 역량 향상 자료 (0) | 2022.11.12 |
|---|---|
| Web Server vs WAS (0) | 2022.09.24 |
| 우리가 쓰는 데이터가 컴퓨터에 저장되는 방법 (0) | 2022.05.28 |
| SQL - 기본 (0) | 2021.11.29 |
| 네트워크 - CS 면접 총정리 (0) | 2021.11.23 |