[생활코딩] WEB2 - OAuth 2.0

https://opentutorials.org/course/3405

WEB2 - OAuth 2.0 - 생활코딩

---

1. 역할

• their : 우리가 제어하고자 하는 자원을 가지고 있는 서버라는 뜻에서 Resource Server라고 함.
• user : 우리의 사용자. their 서비스에 회원가입이 되어 있는 상태여야 함. 우리가 제어하고자 하는 자원의 소유자라는 뜻에서 Resource Owner라고 함.
• mine : 우리가 만든 서비스. Resource Server에 접속해서 정보를 가져가는 클라이언트라는 뜻에서 Client라고 부름.

 

• Resource Server와 Client, Resource Owner 삼자와의 관계가 OAuth의 핵심이다.
• 공식 문서에는 데이터를 가지고 있는 서버인 Resource Server와 인증과 관련된 처리를 전담하는 서버인 Authorization Server를 구분해서 보여주지만 이 수업에서는 이 둘을 합쳐서 Resource Server라고 표현함.

 

2. 등록

• 우리의 Client가 Resource Server를 이용하기 위해서는 사전에 Resource Server의 승인을 받아야 한다. 그것을 register(등록)이라고 한다.

 

• 서비스마다 등록하는 방법은 다 다르다.
• Client ID, Client Secret, Authorized redirect URIs는 공통적으로 받는다.
• Client ID : 우리가 만들고 있는 어플리케이션을 식별하는 식별자.
• Client Secret : Client ID에 대한 비밀번호.
• Authorized redirect URIs : Resource Server가 권한을 부여하는 과정에서 Authorized code를 이 주소로 전달해준다. Resource Server는 이 주소 말고 다른 곳에서 요청하면 요청을 무시한다.
• Client ID는 외부에 노출 가능. 하지만 Client Secret은 절대로 외부에 노출되면 안된다.

 

3. Resource Owner의 승인

• 등록을 마치면 Client와 Resource Server는 Client id, Client Secret 정보를 알게 된다.
• client는 redirect URL에 해당되는 페이지를 구현해 놓아야 한다.

 

• client가 resource server가 가지고 있는 모든 기능이 필요한 것이 아니라 resource server의 일부 기능만 필요하다면 모든 기능에 대해서 인증을 받는 것이 아니라 최소한의 기능에 대해서만 인증을 받는 것이 유리하다.

 

• user는 우리의 애플리케이션에 접속한다.
• 접속하는 과정에서 resource server를 사용해야하는 상황이다.

 

• client는 resource owner에게 resource server의 로그인을 요청한다.
• 위 버튼을 클릭하면 https://resource.server/?client_id=1&scope=B,C&redirect_uri=https://client/callback과 같은 링크를 만들어준다.

 

• resource owner가 위에서 생성된 주소로 resource server에 접속한다.
• resource server는 resource owner의 현재 로그인 여부를 확인한다.

 

• 로그인 되어 있지 않다면 resource server는 resource owner에게 로그인하라는 창을 보여준다.
• 로그인에 성공하면 resource server는 접속을 시도하고자 하는 요청의 client_id 값과 동일한 client_id 값이 있는지 확인한다.
• 동일한 client_id의 redirect URL과 접속을 시도하고자 하는 요청의 redirect_uri가 일치하지 않다면 작업을 끝내버린다.

 

• redirect_uri가 일치한다면 resource owner에게 요청의 scope에 해당하는 권한을 client에게 부여할 것인지를 확인하는 메세지를 전송한다.
• resource owner가 허용 버튼을 누르면 허용했다는 정보가 resource server에게 전송된다.

 

• resource server는 resource owner의 user id와 허용한 scope에 대한 정보를 수집한다.

 

4. Resource Server의 승인

• resource server는 임시 비밀번호 개념인 authorization code를 위의 url 형식으로 Location 헤더에 담아 resource owner에세 전송한다.

 

• resource owner의 브라우저는 location 헤더 값에 의해서 resource owner가 인식하지도 못하게 위의 주소로 이동하게 된다.

 

• 이를 통해 client는 authorization code를 갖게 된다.

 

• 이제 client는 resource owner를 통하지 않고 reosurce server에 직접 접속한다.
• grant_type : 4가지의 방법 중 authorization_code 형식으로 3자 간 인증을 한다는 표시.
• authorization_code와 client_secret이라는 두 개의 비밀 정보를 결합해서 resource server에게 전송한다.
• resource server는 client가 보낸 client_id, client_secret, redirect_uri, authorization_code가 완전히 일치하는지 확인한다.
• 정보들이 완전히 일치한 경우에만 다음 단계로 진행된다.

 

5. Access token

• resource server는 authorization code 값을 통해서 인증을 했기 때문에 authorization code 값을 지우고 accessToken을 발급한다.

 

• resource server는 access token을 client에게 응답해준다.

 

• client는 accessToken 값을 내부적으로 저장해둔다.
• client가 4라고 하는 access token으로 접근했을 때 resource server는 b와 c의 권한을 가진 user id 1번 사용자의 정보를 허용해준다.

 

6. API 호출

• API : Application Programming Interface
  • access token을 가지고 resource server가 client들에게 제공하는 resource server 사용 방식

 

• client가 resource server를 호출해서 작업을 할 때, resource server를 호출하는 접점에 있는 조작 장치가 API.

 

• api에 요청을 보내기 위해선 access token을 함께 보내주어야 한다.
• access token을 보내주는 방법으로는 쿼리 파라미터에 담아주는 방법(?access_token=<access_token>)과 헤더에 담아주는 방법(Authorization: Bearer <access_token>)이 있다.
• 쿼리 파라미터에 담아주는 방법 보다는 헤더에 담아주는 방법이 더 안정성이 높아 선호된다.

 

7. Refresh token

• access token은 수명이 있다.
• 그 수명이 끝나면 해당 access token으로 접속해도 api가 데이터를 주지 않는다.
• 따라서 access token을 다시 발급 받아야 하는데, 그럴 때마다 사용자에게 위의 과정을 다시 거치게 하는 것은 쉽지 않은 일이다.
• 이런 경우 사용자가 쉽게 access token을 재발급 받게 할 수 있는 방법이 refresh token이다.

 

1. (A) Authorization Grant : client가 authorization server로 부터 권한을 획득한다.
2. (B) Access Token & Refresh Token : client는 authorization server로부터 access token과 refresh token을 발급 받는다. (refresh token은 발급해주지 않는 경우도 있음)
3. (C) Access Token : access token과 refresh token을 모두 가지고 있다가 resource server에 access token을 제출한다.
4. (D) Protected Resource : 제출한 access token으로 resource server의 resource를 가져온다.
5. (E) Access Token : client는 가지고 있는 access token으로 계속 resource server의 resource를 요청한다.
6. (F) Invalid Token Error : access token의 수명이 끝나 resource server의 resource에 접근할 수 없게 된다.
7. (G) Refresh Token : client는 가지고 있던 refresh token을 authorization server에 전달한다.
8. (H) Access Token & Optional Refresh Token : authorization server는 client에게 access token을 다시 발급해준다. 경우에 따라서는 refresh token도 새로 발급되는 경우도 있다.