1. OAuth의 원리

우리가 OAuth가 왜 필요한지를 일단 먼저 알아야 한다.

OAuth는 3자가 등장한다. 예를 들어, 문자 메시지는 양자 간의 채팅이기 때문에 구현이 간단하다. 하지만 최근 많이 사용하는 카카오톡과 같은 단체 채팅은 복잡성이 기하급수적으로 늘어난다. 그렇기 때문에 OAuth가 복잡하고 꼼꼼히 공부해야 한다.

 

1. 상황 제시

클라이언트가 나의 서비스를 통해 글을 작성한다고 하자.

여기서 클라이언트는 User, 나의 서비스는 My라 칭하겠다.

이러한 상황에서 나의 서비스는 자동으로 Facebook이나 Google의 캘린더 같은 서비스(Their)에 자동으로 알림이 가도록 서비스해야 한다면, 과정에서 가장 중요한 부분은 보안이다.

My는 User대신에 Their 서비스에 접근하여 제어할 수 있는 인증절차가 필요한 것이다. 

이때 가장 쉬운 방법이 User의 id나 pw를 Their에 전달하는 것이다.  

 

2. 한계점

가장 쉬운 방법으로 User의 id와 pw를 Their에게 전달한다 했다.

하지만 이 방법은 3자 모두가 꺼림칙하다.

1. User입장에서는 믿을 수 없는 My서비스에 전달해줘야 한다는 것이다. 보통 유저들은 자신의 비밀번호를 다른 사이트에서도 동일하게 사용하는 경우가 많기 때문에 한 번의 노출은 모든 서비스에 영향을 줄 수 있다.

2. My입장에서는 User의 id와 pw를 저장하고 있다가, 유출이나 해킹사고가 일어났을 경우 곤란한 상황에 처할 수 있다.

3. Their입장에서는 User가 자신의 서비스에서 사용되는 비밀번호를 알아서 노출해버린 셈이다.

 

3. 해결책

 User가 My를 거쳐 Their를 사용하기 위해 id와 pw가 아닌 임시 비밀번호로 인증할 수 있다. 이 방식으로 한계점 1의 문제를 해결할 수 있다. 또한 일반적인 아이디에 대한 비밀번호는 특정 서비스의 모든 기능에 대한 권한을 의미한다. 하지만 임시 비밀번호로 사용할 시 특정 기능에 대한 권한만 부여하고, 권한 부여 기간을 정할 수도 있기 때문에 더욱 안전하다.

 이러한 방식이 AOuth이며, 여기서 사용되는 임시 비밀번호를 OAuth에서는 access-token이라 불린다.

또한 여기서 User는 Resource Owner(정보의 소유자), My는 Client, Their는 Resource Server(정보 제공자)라고 불린다.

원래 OAuth는 Authorization Server라는 별도의 서버가 Their에 존재하지만 이번 학습에서는 Resource Server와 같은 것이라 칭하겠다.

 

 

4. 원리

 마치 아이가 태어나면 출생신고를 하고, 주민등록번호를 발급받는다. 또한 우리는 이름과 주소등을 제공하여, 정해진 정보를 양쪽이 다 동일한 정보를 가지고 있게 된다. 이것처럼 OAuth에서도 동일한 정보를 Client가 Resource Server에게 요청하면서 인증절차를 걸치게 된다.

- Client의 요청 -> Resource Server의 정보 생성 : client id, client secret, redirect uri, auth code, access token, user id

         -> Client의 요청에 대한 응답 : client id, client secret, redirect uri, auth code, access token

- client id, client secret : 인증에 대한 id와 pw 개념.

- redirect uri : Reource Server가 생성한 정보를 callback받을 uri.

- access token : 임시 비밀번호