간단하게 말해 OAuth는 구글과 같이 안정적이고 대중적인 서비스 업체에서 사용되는 기능을,
다른 서버의 사이트에서 이용하고 싶을 때 필요한 인증과정이다
단순하게 다른 사이트의 서비스를 이용하기 위해 클라이언트가 타 사이트에 자신의 구글아이디와 비밀번호를 전달해주고, 그 사이트에서 그 정보가지고 가입해서 필요한 내용을 사이트에 띄우는 것은 보안적으로도 말도안되는 소리고 효율적이지도 못하다.
그러니, 그것을 해결하기 위한 방법으로 인증을 위한 토큰전송을 실행하는 것으로 해결한다
OAuth에는 중요한 3가지 주체가 있다
*OAuth를 사용하기 위한 방법은 이러하다**
(모든 과정은 우리가 평소 구글로 로그인하기와 같은 서비스 사용했던걸 연상하면서 보자)
서비스 주체마다 다르지만, 공통적으로 자신의 앱을 등록함으로서 받아오는 정보는
해당 버튼들은 특별한게 아니라, 그냥 Resource Server 주소에 쿼리로 clinetId와, scope, redirect uri 을 붙여 요청하는 기능이다.
https://resource.server?client_id=1&scope=B,C&redirect_uri=https://client/callback
와 같이 버튼을 누르면 예를 들어 상단에 있는 주소로 이동하도록 하는것과 같다.
////////////////////////////////
client id <-- 타사 앱의 아이디
client secret <-- 타사 앱의 시크릿 키
redirect uri <-- 타사 앱이 등록해놓은 redirect 주소
owner id <-- 허가를 누른 owner의 아이디
allowed scope <-- onwer가 동의한 서비스의 범위
////////////////////////////////
// http response
header : {
location : https://client/callbeck?code=3
}
와 같이 말이다. 그러면 브라우저는 자동적으로 받아오는 응답에 있는 location에 따라 이동을 하게 된다. 해당 location에 있는 redirect 주소에 따라 클라이언트측에서 서버에 요청을 날린다(클라이언트의 서버)
그러면 클라이언트 서버는 해당 코드정보와 자신이 갖고있는 clientId, clientSecret, redirectUrl을 전부 합쳐서 resource server에다가 요청한다
(참고로 리소스 서버에 응답을 날리는 것은 Oauth의 형태마다 다르다)
https://resource.server?code=3&redirect_uri=https://client/callback&client_id&client_secret
그 후, 단기간 접속 허용증인 "AccessToken" 을 응답내용으로 client에 전송해준다.
(보통 refresh용 토큰도 같이 발급된다)
body등을 통해 받아온 이 엑세스 토큰을 client는 보유한 상태로 resource server의 서비스를 활용해야 하는 상황의 요청이 owner로부터 올 때마다 해당 토큰을 resource server에 붙여주면서 사용하면 되는 것이다.
만약 access token이 만료되면, 서버측에서 거절이 날아올것이다
그러면 client는 refresh 토큰을 전달하면서 다시 access token을 달라고 요청하고,
해당 요청이 허용된다면 access token을 재발급받고,
resource token마저 만료된 상황이면, 즉 owner가 허가를 한 이후로 꽤나 오랜시간이 지나서 refresh 토큰이 만료되었다면, 아까 처음 부터의 과정을 다시 진행하게 된다.(즉, server에 allow 관련한 주소로 요청하는 버튼 누르게하고, 임시코드받고, 전달받은 임시코드로 시크릿과 함께 서버에 전송하고, 대조되어서 맞으면 accesstoken 발급받고, refresh 토큰 발급받고)