oauth의 동작원리

사용자의 데이터를 구글이나 페이스북과 같은 다른 서비스에서 가져와서

그 정보를 가공하여 사용자에게 가치를 전달하고 싶다면 우리는 oauth를 사용할 수 있다.

 

우리가 사용자에게 제공하고자 하는 서비스는 클라이언트,

우리의 서비스를 사용하는 사용자는 리소스 오너,

사용자의 정보를 가지고 있는 구글이나 페이스북과 같은 회사는 리소스 서버라고 가정하자.

 

클라이언트가 사용자에게 리소스 서버의 아이디와 패스워드를 물어보고, 그것을 저장했다가 필요한 경우

리소스서버에 해당 아이디와 패스워드로 접속하면 사용자에 대한 정보를 가져올 수 있다. 

하지만 여기서 보안이라는 중요한 문제점이 생긴다. 리소스 서버는 클라이언트를 어떻게 믿고 사용자의 아이디와 패스워드를 줄까? 사용자의 데이터는 아주 중요한 정보이기 때문에, 최근에 oauth라는 방식이 등장하였다.

 

동작의 메커니즘은 다음과 같다.

 

1. 클라이언트는 리소스 서버에게 우리는 당신의 서비스를 사용할 것이라고 등록하고,

리소스 서버는 클라이언트에게 서비스를 식별할 수 있도록 id값과 secret값을 발급해준다. 

클라이언트는 해당 값을 자신의 서버에 잘 저장해둔다. (여기서 secret값은 특히 노출되면 안되는 중요한 정보)

 

2. 리소스 오너에게 클라이언트가, 내가 당신의 어떤 정보를 사용하겠다고 리소스 서버에게 허락을 받아달라는 요청을 한다.

ex) 리소스 오너가 클라이언트에 접속하면 "리소스 오너의 모니터에 @@한 이유로 구글의 캘린더 정보가 필요합니다. 구글에 접속해서 우리 서비스가 그것을 사용할 수 있도록 승인해주세요" 라는 창이 뜬다.

리소스 오너가 수락하면 자동으로 리소스 서버에 접속하게 되면서, 리소스 서버는 "현재 이 클라이언트가 당신의 정보를 사용하려고 합니다. 이것에 동의하면 버튼을 누르세요" 와 같은 창이 뜨고,

리소스 오너가 동의하면 리소스 서버는 "리소스 오너가 클라이언트에게 정보를 주도록 승인했다"는 것에 해당하는 정보를 클라이언트에게 주는데 이 정보를 코드라고 한다. 코드는 일종의 비밀번호 같은 것이다.

 

3. 클라이언트는 리소스 서버가 준 코드 값과 자신이 원래 보관하고 있던 id값, secret 값을 담아 리소스 서버에게 다시 보내고, 리소스 서버는 자신이 클라이언트에게 발급한 코드 값과 id값, secret 값을 비교하여

지금 권한을 달라고 하는 클라이언트가 리소스 오너가 승인한 클라이언트가 맞는지 검증한다.

검증결과 코드와 id값, secret 값이 모두 유효하다면 리소스 서버는 클라이언트에게 access token 값을 발급해주고,

클라이언트는 access token의 정보를 자신의 데이터베이스나 파일에 보관한다.

 

4. 클라이언트는 액세스 토큰으로 리소스 서버에 리소스 오너의 정보를 요청한다. 

리소스 서버에 엑세스 토큰 값을 제출하면 리소스 서버는 자신이 발급한 적이 있는 값이면 정보를 주고,

클라이언트는 그 정보를 가공해서 리소스 오너에게 가치를 전달한다.