Oauth이야기
현재 프로젝트에서 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 로 구글 검색을 하게되면, 해당 내용에 대한 표준안을 확인해 볼 수 있다.
Author And Source
이 문제에 관하여(Oauth이야기), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@groovejumat/Oauth이야기저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)