[O-Auth] O-Auth란 무엇인가?

O-auth는 한마디로 말해 인터넷 사용자가 특정 웹 리소스에 대한 접근 권한을 제3의 서비스에게 안전하게 위임할 수 있게 해주는 개방형 표준이다. 

 

기본적으로 제 3의 웹사이트에서 다른 웹사이트의 로그인 권한을 위임 받을땐 아래와 같이 세가지의 주체가 등장한다.

 

• User : 웹 서비스를 사용하려는 유저를 일컫는다.
• Mine : 내 서비스, 즉 내가 권한을 갖고 있는 나의 웹 사이트 이다.
• Their : 나의 서비스가 연동하려고 하는 그들의 사이트 이다.

 

예를 한번 들어보자. 예를 들면,  User가 지금 mine, 즉 내가 제공하는 서비스에 있다고 해 보자. 유저는 다음과 같은 액션을 취하려고 한다.

 

• opentutorials.org 에서 한달짜리 멤버쉽 구독을 한 후, 그 구독 내용을 Google Calendar에 표시하고싶다.
• opentutorials.org 에서는 이제 User의 정보를 통해 Google Calendar의 승인을 받아야 우리가 사용자의 calendar에 접근 할 수 있다.

위와같은 로직을 구현하기 위한 가장 간단한 첫번째 방법은 아래와 같다.

 

• mine에서는 User로 부터 아이디와 비밀번호를 입력받는다.
• 그 입력받은 로그인 정보를 가지고 third party의 로그인 정보에 위임 시킨다.

이렇게 보면 엄청 간단한 일이지만, 절대 이렇게 해서는 안된다. 그 이유는 Google은 모든 유저들이 믿고 쓸 수 있는 웹 브라우저이며, 우리는 Google에게 우리의 google 로그인 정보를 줘도 아무 문제가 없다. 그렇지만, 반대로 생각해보면, 처음 보는 웹사이트에 들어갔는데 갑자기 "Google 아이디와 패스워드를 입력하시오" 라고 써있다면, 가장 먼저 스캠 의심을 할 것이다. 즉, 보안상의 이유로 이러한 방법은 절대 권장되는 방법은 아니며, 그저 예를 들기 위한 하나의 예시였다는걸 기억하자!

 

자 그럼, 이번엔 oAuth를 사용할때 어떻게 동작하는지 살펴보자.

 

이제 우리의 서비스에서 유저의 로그인 정보를 들고 있는 대신, 유저의 요청에 의해 'Their'는 유저의 로그인 정보 대신 'Access Token'을 발급한다. 이 토큰을 통해 'Their'에 접속한 후, 정보를 수정, 추가 할 수 있다.

 

이 Access Token엔 몇가지 장점이 있다.

• 유저의 로그인 정보는 포함되어있지 않다.(보안 문제에서 단순히 유저의 로그인 정보를 주고 받는것보다 훨씬 안전하다)
• Google의 모든 기능이 아니라, 내 서비스에서 필요한 필수적인 기능만 제공 할 수 있다.(캘린더)

여기까지가 기본적인 O-Auth의 내용이다. 위에선 직관적인 설명을 위해 user, mine, their과 같은 라벨을 사용했지만, O-Auth를 사용하기 위해 알아야 할 라벨들을 알아보자.

 

• Resource Server(Their) : 우리가 제어하고자 하는 자원(캘린더)를 갖고있는 서버이다. 즉 위의 예시에서는 구글이 될 것이다.
• Resource Owner(User) : 그 자원(구글 로그인 정보)를 소유하고 있는 유저.
• Client(Mine) : Resource Server 에 접속해서 정보를 가져가는 클라이언트
• Authorization Server : 유저의 인증 정보만 담당하는 별개의 서버이지만, 그냥 Resource서버와 비슷하다고 생각하면 훨씬 이해하기 편하다. 

※ O-Auth 등록하기

 

 

아래 그림과 같이, Client(내가 만든 서비스)가 Resource Server의 리소스(유저의 로그인 정보)를 이용하려면 먼저 리소스 서버의 승인을 사전에 받아놓아야 한다. 이를 Register 한다고 한다.

 

등록하기 위해 필요한 정보들은 각 서버마다 다르지만, Client ID, Client Secret, Authorized redirect URIs등은 공통적으로 이용된다.

 

• Client ID :  우리가 만들고 있는 애플리케이션을 식별하는 식별자
• Client Secret : Client ID에 대한 비밀번호 [Client ID는 외부에 노출이 되어도 되지만, Client Secret은 절대로 외부에 노출이 되어서는 안된다]
• Authorized redirect URIs : Resource 서버를 요청하는 주소이다.

※ O- Auth 인증절차

등록 과정을 거쳤으니, 이제 어떠한 방법으로 인증을 받는지 알아보자.

먼저, 등록을 하게되면 가장 먼저 Client와 Resource Server는 동시에 두가지 정보를 얻게 된다. 위에서 설명한

Client id, Client Secret을 얻게 된다.

 

 

그런데 여기서 짚고 넘어가야 할 부분이 있다. Client는 Resource Server에게 우리가 무슨, 어떠힌 서비스를 원하는지 알고 있어야 한다. 예를 들어,  우리는 구글에서 '캘린더' 서비스만 이용하고싶은데, Resource Server(구글)에서는 켈린더 뿐만 아니라 Docs, Meeting, Mail, Maps등등 여러가지 서비스를 제공한다. 하지만, 나머지 기능들은 우리가 쓸 필요가 없기에 굳이 요청 할 필요는 없다.

 

간단한 예를 들어보자. Resource Owner, 즉 유저가 Client(내가 만든 서비스)에 접속중이라고 가정해보자. 여기서 위의 시나리오처럼 유저는 내가 만든 서비스에서 제공하는 플랜을 구독하고, 그 구독 내용을 Google Calendar에 기록하고 싶다고 해 보자. 그러면 유저는 아래와 같은 화면을 볼 것이다.

저 '버튼'의 내용은 위에 써있는대로 클라이언트 아이디, scope(어떤 어떤 기능들을 쓰고 싶은지)를 명시 해주고, uri를 포함 시켜주면 된다.

 

여기서 유저가 'Login with Facebook' 이라는 버튼을 클릭하면, Resource Server는 유저가 서버에 로그인이 되어 있는지 안 되어 있는지 확인하고, 로그인이 되어있지 않다면, 유저에게 로그인을 하라는 로그인 화면을 보여 줄 것이다. 

 

유저가 로그인을 하면, Resource Server는 그때서야 Client Id가 같은지 확인하고, redirect_uri가 같은지 확인한다. 만약 여기서 redirect_uri가 다르다면, 그냥 작업을 끝내 버린다.

 

그러면 이제 Resource Owner는 user id와 user가 원하는 기능(scope)을 갖고 있는 정보를 저장 할 것이다.

 

----여기까지가 Resource Owner가 인증을 받는 방식이였고, 그 다음은 이제

 

※ Resource Owner가 인증을 받는 법

에 대해 살펴보자.

 

위에서 했던 인증 절차를 마친 후, Resource Server는 authroization code를 생성해 이 코드를 다시 Resource Owner 에게 넘겨준다.

 

이렇게 서버가 유저에게 코드를 넘겨주면,

 

Owner는 서버로부터 받은 주소로 이동을 하게 된다. 그러면 이때, Client는 Owner에게 받은 정보를 통해 Authorization code = 3 이라는 중요한 정보도 같이 받게 된다. 이 코드는, 이제 Client가 Resource Server에 권한을 받을 수 있도록 해주는 key 같은 존재이다.

 

아래 그림과 같이, Client는 Resource Server에게  code과 Client_Secret의 두가지 비밀 정보를 같이 넘겨준다.

 

자 그럼 이제 Resource Server는 어떤 일을 할까?

 

Client로부터 정보를 받은 Resource Server는 이제 authorization code : 3을 이용해 자신(Resource Sever)가 갖고있는 authorization code = 3과 일치하는 정보를 확인 후, Client로부터 받은 authorization code = 3과 일치하는 코드인지 확인한다.

 

authorization code = 3은 어떤 클라이언트 한테 받은 정보인가? (== client 1에게 받은 정보이다), 그리고 그 client id의 secret은 2 이다. 이제 이 모든 정보들이 일치하면 그 다음 단계로 이동한다. 그 다음 단계는 Access Token을 발급하는 일이다.

 

※ Access Token 을 발급받는 과정

 

마지막 부분에서 얘기했던 'authorization code = 3'을 기억해보자. 이 코드는 클라이언트와 리소스 서버간의 인증을 위한 하나의 툴이다. 하지만 o-auth의 Access Token발급 당시에는 클라이언트와 리소스 서버는 이 정보(authorization code)를 지워 버린다. 그 다음, 드디어 리소스 서버는 Access Token을 발급한다. 

 

그런 다음, 이런 식으로 Access Token을 클라이언트에게 응답 해준다. 그러면 Client는 AccessToken:4 라는 중요한 정보를 내부적으로 저장 할 것이다. 이 저장된 토큰을 가지고 리소스 서버에 요청을 보내면, 이 서버는 AccessToken : 4 라는 정보를 가지고 서버 데이터베이스에 있는 AccessToken : 4를 찾아 Client id가 1인지 확인 한 후, 모든 정보가 일치하면 그때 로그인 권한을 부여한다.

(이럴거면 처음부터 AccessToken을 주고 받으면 될걸 왜 처음에 client id, client secret을 만들었는지 모르겠다. 아마 보안 때문이겠지...)

 

그럼 여기까지가 AccessToken 을 발급 받기까지의 과정이였다. 다음 포스팅에서는 AccessToken을 활용해서 Resource Server를 핸들링 하는 법을 알아보자.

 

 

이미지 출처 : 생활코딩 Youtube