OAuth 2.0

(구글 플레이 스토어x) 개발자 콘솔에 앱을 등록하면 앱마다 Client Id, Client Secret이 주어진다.

ex) Client Id- 1, Client Secret- 2

앱 등록후 앱 셋팅과정에서 Redirect url을 등록한다.

ex) Redirect url- https://client/callback

 

앱을 등록한 시점에서 서로 알고 있는 정보들

Resource Server 입장- Client Id, Client Secret, Redirect url

Client 입장- Client Id, Client Secret, Redirect url

---

구글 로그인을 예로 들어보자.

MyApp- Client(구글 서비스에 대해 클라이언트에 해당)

MyApp을 사용하는 구글에 회원가입에 되어있는 사용자- Resource Owner

구글 인증 서버- Resource Server(서비스 제공자. 생활코딩에서 편의상 Resource Server라고 설명한다. 실제로는

사용자 인증을 하는 서버 Authorization Server+ 구글 사용자의 정보가 있는 Resource Server 로 구성되어 있다.)

 

MyApp을 사용하는 사용자가 MyApp에서 구글로 로그인 버튼 ui를 누르면

https://구글서버.com/?client_id=1&scope=b,c&redirect_url=https://client.callback

링크를 제공할 수 있도록 설계한다.

 

우리가 등록할 시 발급받은 id,password 우리가 설정한 redirect url

scope-  우리의 앱에서 사용할 우리 앱 사용자에 대한 구글,네이버등등 서비스

ex) 사용자의 구글 캘린더, 사용자의 페이스북 글, 사용자의 네이버 프로필 등 

총 4개로 구성된 url을 설계한다.

---

1. Resource Owner의 승인

Resource Owner(구글에 회원가입이 되어있는 우리의 앱 사용자) - Authorization Server간 과정

 

MyApp을 사용하는 사용자가 우리의 앱에서 구글로 로그인 버튼을 누르면 버튼에 설정된 url이 구글 인증 서버로 전달된다.

구글 인증 서버에서 사용자의 구글 로그인 상태를 확인한다.

로그인이 안되어있다면 로그인 ui를 보여준다.

 

Resource Owner가 구글 로그인에 성공했다면 Resource Server는 그때서야 바로 전에 Resource Owner가 버튼 클릭시 넘겨주었던 url의 Client id과 Redirect url이 자신의 구글 인증서버에 등록된 것과 일치하는지를 확인한다.

인증 서버에 등록된 앱이라서 Client id는 맞지만 Redirect url이 잘못되었으면 그 상태에서 작업이 중지된다.

Client id, Redirect url이 모두 일치하면 

 

Resource Server가 scope(해당 기능에 대한 권한)에 대한 권한을 MyApp에서 사용할 수 있게 할 것인가를 확인시키는 메세지가 담긴 ui를 Resource Owner에게 전달한다.

(MyApp에서 사용자의 ...기능을 사용하도록 하시겠습니까. 거부. 동의)  

 

허용을 누르면 허용 메세지가 Resource Server로 전달이된다.

이 사용자의 구글 id가 1이고 MyApp에게 제공할 서비스가 b,c였다면 인증서버에 id-1, scope-b,c를 등록한다.

(user 1은 b,c의 기능,권한에 대해 MyApp이 사용할 수 있도록 허용하였다.)

 

여기까지가 사용자(Resource Owner)로부터 구글(Resource Server)에 동의를 구하는 구하는 과정이다.

---

2. Resource Server의 승인

Resource Server가 인증을 처리하는 과정

 

여기서 바로 Access Token을 발급하지 않고 절차가 하나 더 있다.

임시 비밀번호인 Authorization code를 발급한다.

Resource Server가 Location:https://client.callback?code=3을 Resource Owner에게 전달한다.

헤더값에 의해 Resource Owner는 https://client.callback?code=3으로 이동하게 된다.

Client는 code=3을 통해 Authorization code가 3임을 알게된다.

 

현재 서로 알고 있는 정보들

Resource Server 입장- Client Id, Client Secret, Redirect url, userid, scope, Authorization code

Client 입장- Client Id, Client Secret, Redirect url, Authorization code

 

Client가 Resource Server로부터 access token을 발급받기 위해 

authorization code, client id, client secret, redirect url이 담긴 url을 Resource Server에 전달한다.

 

Resource Server는 전달 받은 authorization code를 확인한다. 해당 authorization code가 있으면 

코드에 해당되는 앱이 맞는지 client id, 앱 등록시킬때 준 비밀번호는 제대로 사용했는지 client secret 

, redirect url도 체크한다.

내용이 모두 맞아 인증이 완료되면 Resource Server는 authorization code를 지워버린다.

그리고 Client에게 access token(4라고 가정)을 발급해준다.

 

 

이 access token을 안 잊어버리도록 잘 보관한다.

이후에 Client가 이 access token 4값으로 Resource Server에 접근하면 userid-1 의 기능 b,c에 대한 정보들을 

Client에게 넘겨준다. 이 access token으로 사용자1의 기능 b,c를 수정 읽기 삭제등의 작업들이 가능하게 한다.

 

각 개발자 사이트 서비스 기능에 대한 api를 잘 섞어 access token과 같이 넘겨주면 적절한 응답을 받을 수 있다.

 

Refresh Token

Access Token은 수명이 정해져 있다.( 사용하는 서비스마다 다르다) 수명이 다된 access token으로 접근하면 api로부터 응답을 받지 못해서 Refresh Token으로 access Token을 발급 받는다.

access token발급시 Refresh Token을 같이 받을 수 있는 곳도 있고 , Refresh Token으로 access token을 재발급 받을시 Refresh token도 재발급 되는 경우가 있다고 한다. 사이트마다 다르니 잘 읽어보는게 좋을 듯 하다.

 

꼭 기억해야 할 것들

redirect url

authorization code

access token

refresh token

---

OAuth 2.0 생활코딩 강좌

 

https://opentutorials.org/course/3405

WEB2 - OAuth 2.0 - 생활코딩

1. Resource Owner, Authorization Server(+Resource Server), Client

2. Client ID, Client Secret, Redirect URL, Authorization Code, Access Token, Refresh Token에 대해 잘 설명되어 있었다.

---

OAuth 2.0 -rfc문서

 

https://datatracker.ietf.org/doc/html/rfc6749

rfc6749

---

rfc란

 

https://ko.wikipedia.org/wiki/RFC

RFC - 위키백과, 우리 모두의 백과사전