OAuth의 배경
3자가 약속을 정하려는 데에 소통의 어려움이 따르듯, 인증과정에 참여하고 있는 3자가 한자리에 모일 수 없는 상황에서 어떻게 하면 서로를 신뢰할 수 있을까를 고민하며 등장한 기술입니다.
OAuth의 주체
- Resource Owner(User): Resource Server와 Client의 사용자
- Client(Mine): 내가 운영하는 어플리케이션
- Resource Server(Their): Resource Owner 대신 Client가 접촉해야하는 대상, 데이터를 가지고 있는 서버
- Authorization Server: 인증을 전담하는 서버(이후 Resource Server로 통칭)
OAuth 등록 절차
우선 Client가 Resource Server에 접근하기 위해서는 사전 준비가 필요합니다.
- Client ID: 나의 어플리케이션 식별자 ID, 외부에 노출
- Client Secret: ID에 대한 비밀번호, 노출 X
- Authorized redirect URL: Resource Server가 권한을 부여하는 과정에서 전달돼야하는 Authorized Code의 안착점
Resource Owner의 승인
이제 준비가 완료됐으니 사용자의 허락을 구해야겠습니다.
우선 위의 등록 과정을 통해 Client와 Resource Server 둘 다 Client ID, Client Secret, Authorized redirect URL을 알게 됩니다.
Resource Server가 제공하는 기능 A, B, C, D 중 우리는 B, D를 사용하길 원합니다.
그렇다면 모든 기능에 대해 승인을 얻기보단, 필요한 기능만 승인을 받는 것이 좋겠습니다.
그 후 우리는 Resource Owner에게 B, D의 기능을 사용해야함을 알리고, 유저가 소셜로그인 버튼을 클릭했을 시에 https://resource.server/?clint_id=1&scope=B,D&redirect_uri=https://client/callback로 연결되게 하면 되겠습니다.
그러면 Resource Server가 Resource Owner의 로그인 여부를 체크하고난 후, Client ID와 Redirect URL이 일치하는 지를 확인합니다. 이 모든 것이 같다면 Resource Owner에게 Client가 사용하길 원하는 Scope에 대한 동의를 할 것인지 알리고, 허용을 한다면 Resource Server에 user_id와 동의된 scope가 기록됩니다.
Resource Server의 승인
Resource Owner의 동의를 확인하자마자 Client에 Access 토큰을 부여하지 않습니다.
3자 간의 일이니 신중해야하는 것이지요.
authorization code(임시 비밀번호)를 담은 location(https://,,,/code=3)을 owner에게 전달하여 이동을 권고합니다.
그렇게 타고들어온 유저를 통해 Client는 authorization code를 취득하게 됩니다.
이후 Client는 Server에 authorization code와 client_secret 두개의 비밀정보를 담은 주소로 server에 직접 접속합니다. server는 전달 받은 정보를 확인하고, 모두 일치한다면 Access 토큰을 발급하게 됩니다.
Access Token 발급
임시비밀번호인 authorization code를 삭제하고, accessToken을 발급하여 Client에 응답해줍니다. Client는 전달 받은 토큰을 저장하고, 이후 Client가 token을 가지고 server에 접근할 때 해당하는 유저가 허용한 scope에 대한 권한을 부여합니다.
