OAuth 2.0 - Authorization Code Grant 방식의 흐름 (생활코딩)

1. Client 등록 

클라이언트가 리소스 서버를 이용하기 위해서는 리소스 서버의 승인을 사전에 받아야 한다 

 

서비스마다 다르지만 등록시 Client ID, Client Secret, Authorized redirect URI를 공통적으로 받는다

 

앱(클라이언트)을 새로 생성하면 서버에서 Client_ID와 Client_Secret을 발급한다
Client_ID -> 클라이언트을 식별하는 아이디

Client_Secret -> 클라이언에 대한 비밀번호

Authorized Redirect URI는 클라이언트 등록시 클라이언트가 입력하는데

이 URI는 리소스서버가 권한을 부여하는 과정에서 클라이언트에게 authorization code를 전달해줄 때 필요한 주소이다.(뒤에 자세한 설명)리소스 서버는 저 주소가 아닌 다른 곳에서 승인요청을 하면 무시한다

 

---

2. Resource Owner의 승인

 

등록과정에서 리소스 서버와 클라이언트는 각각 Client id, Client Secret, redirect URI를 가지게 된다

클라이언트는 redirect uri 페이지를 구현해놓고 준비해놓아야한다 (뒤에서 설명)

 

 

리소스 서버가 가지고 있는 기능이 a,b,c,d이고 클라이언트가 b,c만 필요하다면 

모든 기능에 대한 인증이 아니라 최소한의 기능에 대해서만 인증을 받는 것이 효율적이다

 

 

리소스 오너는 클라이언트에 접속을 하는데 접속을 하는 과정에서 리소스 서버를 사용해야하는 과정이 있다면 (예를 들어 페이스북에 글을 기록한다든지 구글 캘린더에 일정을 입력한다든지) 클라이언트는 리소스 오너에게 다음과 같은 화면을 보여줄 것이다 (OO로 로그인하기)

 

 

로그인 버튼들은 다음과 같은 링크를 뜻한다

Client_id(클라이언트 아이디 값), scope(클라이언트가 사용할 기능), redirect_uri(authroizaiton code를 전송할 링크)에 관한 정보가 담겨있는 링크

 

리소스 오너가 리소스 서버로 접속을 저 링크로 하게 되면 리소스 서버가 리소스 오너가 로그인이 되어있는지 안되어있는지 확인하고 로그인이 안되어있다면 로그인을 하라는 화면을 보여준다

 

 

리소스 서버는 그때 client id 값과 redirect uri이 동일한지 확인하고 다르면 작업을 끝내버린다
client id값과 redirect uri가 같다면 리소스 오너에게 scope에 해당하는 권한을 클라이언트에게 부여할 것인지 확인하는 메시지를 전송한다

 

 

 

해당 기능에 대한 허용버튼을 누르면 허용했다라는 정보가 리소스 서버로 전송이 되고,  
리소스 서버는 user_id 1번(resource owner의 회원아이디)이 다음과 같은 b,c 작업을 허용하는 것에 동의했다라고 하는 정보를 저장(db나 file에 저장)

 

이러한 과정을 완료하면 Resource Owner 에 대한 승인을 획득

 

 

---

3. Resource Server의 승인

Resource Server가 Client를 승인하기 위해서 바로 Access Token을 발급하지 않고 그 전에 절차가 하나 더 있는데 바로 authorizatino code이다. (화면에 짤렸지만 authroziation code:3 이다)

resource server가 resource owner에게 authorization code 전달 
Location : https://client/callback?code=3 과 같은 방식으로 전달

 

 

 

리소스 서버가 리소스 오너의 웹브라우저에게 헤더라고 하는 값으로 location이라는 값을 준다
뜻 - 웹브라우저한테 https://client/callback?code=3로 이동하세요라고 명령

 

그렇게 되면 리소스 오너의 웹브라우저는 location 헤더값에 의해서 리소스 오너가 인식하지도 못하게 
https://client/callback?code=3로 이동한다 
그러면 코드 3번이라는 값에 의해 클라이언트는 authorization code : 3을 갖게 된다

 

 

 

클라이언트는 리소스 오너를 통하지 않고 리소스 서버에게 직접 접속한다

https://resource.server/token?grant_type=authorization_code&code=3&redirect_uri=https://client/callback&client_ud=1&client_secret=2

grant type - 인가 승인 유형 (4가지가 있다)
code - authorization code (예제에서 code=3) 
redirect_uri, client_id, client_secret를 결합해서 리소스 서버에게 전송

리소스 서버는 authorzation code 3번을 보고 client_id와 client_secret, redirect_uri값이 완전히 일치하는지 확인하고
일치하면 액세스 토큰을 발급한다

 

리소스 서버의 클라이언트 승인 완료 -> OAuth의 목적 액세스 토큰 발급

 

---

4. 액세스 토큰 발급

 

리소스 서버는 authorizatino code를 통해서 이미 인증을 완료했기 때문에 다시 인증과정을 거치지 않기 위해 authorization code를 지운다 (resource server 와 client 둘다)

 

 

리소스 서버는 Access Token을 발급해서

클라이언트에게 전송해주고 클라이언트는 전달받은 access token을 저장한다

클라이언트가  access Token 4를 가지고 리소스 서버에 접근하면,

리소스 서버는 이를 보고

 

"아 이 토큰은 유저아이디(user_id) 1번에 해당하는 유효한 기능(scope) b,c에 대해서 권한이 열려있는 키니까 클라이언트에게 이 권한에 대해 허용을 해야겠다"

 

고 인식한다