[OAuth] OAuth 2.0 소개

1. OAuth이 왜 필요한가?

Cafe24 Login

자신이 운영하는 서비스에 소셜 로그인같은 다른 서비스를 연동시킨다고 생각해보자.
그리고 사용자가 여러분에게 ID, PW를 알려주면, 여러분이 사용자 대신에 SNS 로그인을 해준다고 생각해보자.
그렇다면 사용자들은 과연 안심할 수 있을까? 누구나 어딘가에 자신의 개인정보가 남는 것은 원치 않을 것이다.
이런 문제를 해결하기 위해 필요한 것이 Access Token으로, 이는 인증된 사용자들을 식별하는 토큰이다.

OAuth란?

사용자의 인증 정보를 내 서비스에 넘기지 않고, Access Token을 이용해서 사용자 인증이 필요한 API에 접근할 수 있게 해주는 기술

2. OAuth 용어

1) Resource Owner

- 내 서비스를 이용하는 사용자
- 자원의 소유자

2) Client

- 내 서비스

3) Resource Server

- 내 서비스와 연동되는 서비스
- OAuth 서비스를 제공하고 자원을 관리하는 서버

4) Authorization Server

- Token을 발급해주고, 권한을 관리하는 서버

5) Access Token

- Authorization Server로 부터 발급 받은 Token

3. OAuth의 동작

1) OAuth 등록

먼저, Client가 OAuth를 사용하기 위해 Resource Server에게 승인을 받야아 한다.
이 과정은 연동할 서비스의 개발자 페이지에서 수행할 수 있다.
예) facebook for developers, Google Cloud Platform

등록 정보는 서비스마다 다르지만 공통적으로 가지는 부분은 다음과 같다.
(1) Client ID : Resource Server가 내 서비스를 식별하는 ID
(2) Client Secret : 비밀번호
(3) Authorized Redirect URLs : Resource Server가 Resource Owner에게 Authorization Code를 포함하여 보내는 URL로, Resource Owner은 해당 주소로 이동하게 된다.

OAuth 등록을 성공적으로 마치면, Resource Server와 Client는 저 3개의 정보들을 서로 알 수 있게 된다.

2) Resource Owner의 승인

Client는 Resource Owner가 Resource Server의 서비스를 이용할 수 있게 하기 위한 링크를 제공해 주어야 한다.
그리고 Resource Owner는 해당 링크를 누름으로써 Resource Server에 접근하겠다는 의사표시를 할 수 있다.

해당 링크는 id, scope(사용할 기능의 범위), redirect_uri 등을 포함하여 Resource Server로 전송할 수 있는 주소로 설정하면 된다. 아래 이미지가 이해에 도움이 될 것이다.

Resource Owner가 해당 링크로 이동하게 되면 Resource Server은 URL에 포함된 Client ID가 자신의 서버에 등록된 Client ID 리스트에 속해 있는지 확인하고, 이 Client ID에 해당되는 Redirect URL까지 일치한지 확인한다.
일치하다면, Resource Server은 URL에 포함된 Scope의 권한들을 Client에게 부여 할 것인지 Resource Owner에게 동의 의사를 묻는다.

Resource Owner가 수락했다면, Resource Server은 이 Resource Owner의 ID와 수락받은 Scope를 같이 저장해둔다.

 

3) Resource Server의 승인

Resource Server은 Client가 Resource Owner으로부터 Scope의 권한들을 무사히 부여 받았다는 것을 확인해야 한다.
이를 위해서, Resource Server은 Resource Owner에게 Authorization code를 포함한 Redirect URI을 전송한다.
그리고 이 Redirect URI는 Resource Owner을 걸쳐 Client에게 전송되어 Client는 Authorization code값을 받게 된다.
Authorization code는 Access Token을 받기 위해 필요한 임시 비밀번호이다.

그 다음에 Client는 Resource Server로 Grant type, Authorization code, Redirect URI, Client ID, Client secret을 모두 전송하고, Resource Server은 이 정보들이 모두 맞는지 확인한 뒤에 Authorization Server을 통해 Access Token을 발급 해준다.

 

 

4) Access Token 발급★

Client가 Access Token을 성공적으로 발급받았다면 Authorization code는 더 이상 필요가 없기 때문에 삭제되고, Resource Owner는 안전하게 Resource Server와 상호작용 할 수 있게 된다.

 

 

5) API 사용

이제 모든 인증 절차는 끝났다.

이제 Client는 자신의 서비스에 Resource Server가 제공하는 기능들을 포함시켜야 하는데, 이 때 사용하는 것이 API(Application Programming Interface)다.

API는 특정 응용 프로그램을 사용하기 위한 약속으로, Client는 Resource Server에서 제공하는 API 문서들을 참고하여 API들의 사용법을 파악하고 자신의 서비스에 적용하면 된다.

 

 

 

4. Refresh Token

만료된 Access Token을 갱신하기 위한 토큰이다.

Access Token을 발급해줄 때 Refresh Token을 같이 발급해주는 곳도 있고, Refresh Token을 사용하지 않는 곳도 있다.

Refresh Token 사용법은 서비스마다 다르기 때문에 관련 문서를 찾아보면 된다.

 

 

 

▣ 정보 출처 - 생활 코딩 : https://www.youtube.com/playlist?list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-