OAuth 2.0

개념 정리

내가 제공하는 서비스를 Client, 다른 서비스를 Resource Server, 두 서비스를 모두 이용하는 사용자를 Resource Owner라고 정의한다. 추가적으로 Resource Server에서 인증을 담당하는 서버를 따로 Authorization Server라고 한다.

이렇게 연합해서 인증체계를 제공하는 것을 federated Identity라고 부른다.

 

배경

Client가 Resource Server(google, facebook 등)에 있는 Resource Owner의 계정에 접속할 수 있는 방법은 무엇이 있을까? Resource Server에 대한 Resource Owner의 id, pw를 제공받으면 더 좋겠지만 보안 신뢰 문제가 있다.

따라서 oAuth가 나왔다. oAuth를 이용하면, Resource Owner의 요청을 통해 다른 서비스가 accessToken이라는 일종의 비밀번호를 발급한다. Client는 accessToken을 통해 Resource Server에 접근할 수 있는데, 이 방식은 기존 id, pw를 이용한 방식보다 제한적인 이용을 할 수 있다.

 

등록

우선 Resource Server의 기능을 이용하려면 Client는 등록을 해야한다. 등록하는 방식은 각기 다르지만 공통적으로 받는 요소가 있다.

• Client ID
• Client Secret
• Authorized redirect URIs : Resource server가 Authorized Code 값을 전달해주는 url. 해당 url에서 요청하는 것만 응답함

 

Resource Owner의 승인

등록 후에 Resource Server와 Client는 등록 시에 사용한 정보를 공유하고 있다.

Resource Owner가 Client를 사용하는 과정에서 Resource Server를 사용해야하는 경우가 생기면, Client는 Resource Owner에 인증을 위한 UI를 보여준다. 해당 UI를 통해 Client는 Resource Server에 Client_id, 필요 기능, redirected_url 등을 제공하여 연동한다.

Resource Server는 해당 요청을 받고, Resource Owner에게 로그인을 요청한다. 그 후, Client Id와 redirect URL을 요청에서의 값과 비교하여 같으면 Resource Owner에게 허용할 지를 물어본다.

그러면 Resource Server는 어떤 user에 대해 어떤 Client가 어떤 기능을 사용할 수 있는지를 저장할 수 있다. 응답을 제공한다. (응답은 다음 챕터에)

 

Resource Server의 승인

authorization code(임시 비밀번호)를 Resource Server가 Resource Owner에게 응답으로 제공한다.

Resource Owner는 응답에서의 주소로 이동하게 되면서, Resource Server가 제공한 authorization code를 받게 된다.

그러면 이제 Client는 Resource Owner를 통하지 않고, 바로 Resource Server로 접속하게 된다. 이 때, authorization code, redirect_url, client_id, client_secret을 전송하기 때문에 Resource Server는 주어진 값들을 비교하여 해당 정보가 적합한지를 판단한다.

 

Access Token 발급

Resource Server가 authrization code 값을 양쪽에서 지워버리고 accessToken 값을 발급한다. accessToken을 Client한테 보내주면 Client가 해당 토큰을 저장한다.

이제 accessToken으로 Resource Server에 접근하면 해당 (Client, ResourceOwner, 기능)에 대해 바로 인증이 된다. 방식은 다음 두가지가 있다.

• query로 accessToken 넘기기
  • 노출을 막기 위해 https(TLS)를 반드시 이용해야함
• Bearer Authentication 이용해서 header로 넘기기
• form-encoded body parameter
  • 보안상 이유로 권장 x
• URI Query Parameter
  • 보안상 이유로 권장 x

 

Refresh Token 발급

accessToken은 일반적으로 1시간 정도의 수명이 있다. 해당 수명이 끝나면 더이상 인증이 불가능하기 때문에, 다시 accessToken을 받아야한다.

보통 accessToken과 함께 refreshToken을 발급한 후, accessToken의 수명이 다되면 refreshToken으로 accessToken을 다시 발급받는다.

 

참고

https://opentutorials.org/module/3668

WEB2 - OAuth 2.0