현재 프로젝트에서 Oauth를 붙이는 작업을 진행 중에 있는데, 좋은 글인 것 같다.
따로 Oauth를 해당글에서 추가저긍로 정리도 해놓을 생각이다.
https://d2.naver.com/helloworld/24942
사용자, 나의어플리케이션, 그리고 나의어플리케이션이 사용하려고 하는 "사용자"의 서비스
어떤게 있을까? google, facebook 같은 것들이 있을 것이다.
ex) 나의어플리케이션에 어떠한 글을 작성했을 때에 -> 구글켈린더에 해당 내용을 기록해준다, 혹은 글을 쓴내용을 공유해준다
하지만, 해당 작업을 하려면 그들이 사용하고 있는 그 서비스에 허가를 받아야 한다
제일 원시적인 방법이라면? 그들이 사용하고 있는 서비스에 대한 접속정보를 활용하여 우리가 대신 요청 하는 방법이 있다.
하지만 이 부분은 유저입장에서 매우매우 위험하다.
그리고 내 서비스의 보안적인 책임이 어마무시하게 가중된다.
이러한 서로간의 불편한 상황을 해소하고자 나온 솔루션이 바로 Oauth이다.
이를 통해 우리가 만든 서비스를 그들사용하고 있는 서비스와 상호작용 할 수 있게 된다.
Oauth를 통해 바뀌는 부분
기존에 id, password같은 기본적인 데이터를 통해서 허가가 필요했다면, Oauth를 통해서는 발급되어진 accessToken을 통해서 선택적으로 그들이 사용하고 있는 서비스를 사용할 수 있게 된다.
내 어플리케이션에서는 Oauth를 통해 이러한 AccessToken을 휙득하여, 해당 AccessToken을 통해서 원하는 서비스를 사용하게 된다.
용어를 조금만 정리하자
위처럼 정리하기에는 너무 단어가 길다. 이제 설명을 할 때에는 아래처럼 단순화한다.
user :: 사용자(Resource Owner)
mine :: 내가 만든 서비스(Client)
their :: 사용자가 등록해 놓은 어떠한 서비스 + 우리가 일부분 사용하고자 하는 서비스(Resource Server + Authorization Server)
해당 삼자관계를 꼭 유념하자
등록하기
mine이 their를 사용하기 위해서는 우선 승인을 사전에 받아야한다. (register)
일반적으로는 아래와 같은 조건을 필요로 한다.
Client ID :: Client의 식별자
Client Secet :: Client의 비밀번호(이는 노출되면 안된다.)
Authorized redirect URLs :: 인증이 되었음을 Client에서 받을 수 있게 하는 url네이버 공식내용을 참조해서 따라하면, 해당 인증방식에 대해 이해가 가능하다.
https://developers.naver.com/apps/#/register?api=nvlogin
이제 인증을 해보자 (Resource Owner가 Rersource Server로)
등록이 끝난 상태에서, Client는 등록한 redirectURl을 통해 해당 어플리케이션의 인증상태를 알 수 있게 되었다. (물론 해당 url에 대해 어떠한 처리를 할 것 인지는 Client의 역할이다.)
그럼 이제 어떠한 기능을 사용할 것인지에 대한 선택상황에 대해서 이야기 해보자.
ResourceServer에서 제공하는 기능이 A,B,C,D가 있다고 가정하자.
여기서 Client는 A,C를 사용하고 싶다.
이러한 상황에서 이 세명의 관계가 어떻게 되어지는지 시뮬레이션 해보자.
- 해당 기능을 사용하기위해서 (예를 들면 로그인) Resource Owner에게 이러한 화면을 보여주게 된다.
그리고 간단한 안내문을 보여준다. (간편 인증을 위해서 네이버로그인이 필요합니다.)
해당 버튼에 붙은 url은 우리가 허가등록을 할 때 기재했던 모든 정보들이 들어있다.
-
해당 버튼을 누르게 되면, 실제 Resource Owner는 Resource Server에 실제 해당 유저가 로그인이 되어져 있는지를 확인한다.
(인증만을 목표로 Oauth를 사용하는 경우에는, 해당 프로세스 자체가 Client에서 사용하고자 하는 기능이 된다.) -
로그인이 되어져 있지 않은 경우, Resource Server에서는 아래와 같은 페이지를 보여 줄 것이다.
-
위 화면에서 로그인을 성공하게 되면 그 때 해당 client_id값과 리다이렉트를 할 url의 값이 같은지를 확인하게 된다.
-
모든 조회가 끝나게 되면 resource owner에게 A,C의 기능을 사용 할 것인지를 묻는 확인을 하게 된다. (정확하게는 client가 해당기능을 사용할 것 임에 대해서 확인을 받는 과정이다.)
-
유저가 해당 과정에 동의를 하게 되면, 이를 Resource Server는 해당유저가 A,C기능을 제공하는 것에 동의했음을 저장한다.
-
이렇게 resource owner가 resource server에 동의를 구하는 하나의 프로세스가 끝나게 된다.
Resource Server의 Client 승인 프로세스
-
해당 처리가 끝나게 되면 Authorize_code를 Client에서 설정한 callback_url뒤에 붙여서 날라가게 된다.
-
여기서 resource server가 뒤에 붙여준 값이 "인증 번호"의 역할을 하게 된다.
-
resource owner의 브라우서에서 해당 콜백 url로 리다이렉션이 되어지고, 대상 클라이언트 서버에서는 해당 유저의 "인증 번호"가 무엇인지 휙득하게 된다.
-
client는 "인증 번호"를 가지고 직접 해당 resource server로 요청을 하게 된다. 이 때 아래와 같은 정보를 꼭 포함하여 보내게 된다.
authorize_code :: resource owner가 승인하여 얻은 인증 번호
client_secret :: 클라이언트의 시크릿 키- 요청 받은 resource_server는 상위 모든 값들이 모두 일치하는지 확인하고,
최종 단계인 "AccessToken" 을 발급한다. 이를 Client가 받아서 저장한다.
해당 단계가 끝나게 되면, "인증 코드"가 사라지게 된다.
AccessToken을 통하여 다음을 확인한다.
유저의 정보
유저가 승인한 기능 (A,C)
Client의 시크릿 키Resource Server의 API(Application Programming Interface)사용 방식
이제 A,C의 기능을 사용하려면 API를 사용해야 한다.
이는 해당 서비스에서 제공하는 API문서를 참조해야 한다.
구글캘린더 정보 가지고 올 때,
유저가 체크한 지도 마킹 정보등을 가지고 올 때 등등네이버의 경우에는 Oauth2.0기반으로 아래와 같은 기능을 사용할 수 있음을 알려준다.
https://developers.naver.com/docs/login/profile/profile.md
다양한 언어의 코드 예제를 친절히 제공해 준다.
AccessToken이 끝나게 된다면? 어떻게 될까?
매번 위의과정을 거쳐서 AccessToken이 만료되어질 때마다 발급받아야 한다면 여간 힘든일이 아닐 수 없다.
이를 해소하는 것이 refreshToken이다.
만료되어진 AccessToken을 통해서 에러가 난 경우, Refresh Token을 통해 요청을 하게되면, AccessToken과 선택적으로(서비스 마다 다름) Refresh Token을 다시 보내준다.
상위 이미지는 표준화 되어진 방식으로 구축되어진 Oauth방식이니, 프로세스를 이해하는데에 참조가 많이 될 것이다.
마무리
개념을 익히지 않더라도 예제를 몇개 찾아서 네이버로그인, 카카오로그인 등 Oauth를 붙이는 작업은 전혀 어려운 작업이 아니다. 하지만 이러한 내부적인 흐름을 이해해야, 정확히 제대로 쓸 수 있기 때문에 개인적으로 정리를 하는 시간을 가져 보았다.
팁으로
어떤개념 + rfc 로 구글 검색을 하게되면, 해당 내용에 대한 표준안을 확인해 볼 수 있다.
