OAUTH

WEB2 - OAuth 2.0 : 1.수업소개 - YouTube

모든 내용은 생활 코딩님의 OAUTH강의를 바탕으로 만들어졌습니다.

 

3가지의 주체가 있다고 가정해봅시다. 우리(서버)를 Client라고하고 우리의 서비스를 사용하는 사람(사람)을 Resource Owner

그 정보를 가지고 있는 다른 사이트(카카오,google..)를 Resource Server라고 합시다. Authorization Server라는 것도 있지만 편의상 합쳐서 Resource Server만 사용하기로 한다.

 

client가 리소스 서버를 이용하기 위해서는 리소스 서버의 승인을 사전에 받아놓아야한다. 나는 깃허브를 사용해보려고 한다.

New OAuth Application (github.com)

GitHub: Where the world builds software

이름, 자신의 주소, 그리고 정보를 받아올 주소(Authorization callback URL)를 적어준다. 이렇게 등록을 하면 Client ID와 Client Secret을 나에게 준다.

Client ID는 앱의 식별자이고 노출해도 별 상관없지만  Client Secret은 이것의 비밀번호이므로 절대 외부 노출해선 안된다.

 

Authorization callback URL 이것은 리소스서버가 우리(서버)에게 권한을 부여하는 과정에서
우리한테 autorized code를 전송해주는데 그때 이 주소로 전달을 해달라고 적은 것이다. 

 

이렇게 우리가 등록을 해 놓으면 resource server에는 client의 id, secret, Authorization callback URL이 저장되어 있을 것이다.

물론 client도 그 정보를 가지고 있다.

리소스 서버가 가지고 있는 기능이 A,B,C,D 네개일 경우 client는 모든 기능이 필요한 것이 아니라 B,C만 필요하고 싶을 때 모든 기능에 대해서 인증을 받는 것이 아니라 B,C에 대해서만 인증을 받는 것이 더 좋을 것이다.

 

그 허가를 받기 위한 링크에 우리의 ID의 값과 우리가 원하는 정보 B,C 그리고 응답을 받을 RedirectUrl의 값을 넣으면 된다.

따라서 github로 로그인하기 버튼을 누르면 사용자는 저 주소(링크)로 이동을 한다.

ㅁ

리소스 오너가 링크를 클릭하면 리소스 서버에서 로그인 되어있는지를 확인하고 되어있지 않은 경우에는 로그인 창을 띄운다. 그리고 로그인이 되면 그때서야 !!   URL에있는 클라이언트 ID의값과 일치하는 ID의값이 있는지 리소스 서버에서 확인한다. 그리고 일치하는 ID가 가지고 있는 redirect URL의 값과 URL에 적혀있는 redirect URL의 값이 같은지를 확인하고 만약 다르면 여기서 중단시킨다.

 

즉 리소스 오너가 누른 링크의 ID와 redirect URL의 값이 기존에 리소스서버에 만들어두었던 클라이언트의 ID값과 redirect URL의 값이 리소스서버에서 같은지를 확인한다.

 

그리고 두 값이 맞다면 아래와 같이 리소스 오너에게 SCOPE에 대한 권한(B,C)을 클라이언트에게 부여할 것인지에 대한 확인절차를 거친다.

오너가 동의를 한다면 

리소스서버에는 사용자의 아이디와(user id)

리소스오너가 scope b,c에 대한 작업을 허용하는 것에 동의하였다는 정보를 저장해놓는다.

 

 

리소스 서버는 임시 비밀번호 같은  authorization code를 리소스 오너의 웹브라우저에 보낸다.

그리고 리소스 오너의 웹브라우저는 저 Location 헤더값에 의해 사람이 인식하지도 못할 정도로 빠르게

저 주소로 이동하게 된다. 그리고 클라이언트(서버)는 이로 인해 authorization code를 알 수 있게 된다.

사용자 ->(허가 해줘) 깃허브 ->(코드) 사용자 ->(코드) 서버

 

자 지금 클라이언트가 리소스 서버에게 authorization code를 전송해서 액세스 토큰을 발급 받기 전 단계 까지 온 것이다.

 이제 클라이언트는 리소스 오너를 통하지 않고 아래와 같은 주소로 직접 접속한다. 

비밀정보인 authorization code와 secret을 결합해서 리소스서버에게 전송한다. + client id, redirect url

그럼 리소스 서버는 받아온 authorization code을 보고 자기가 가지고있는 authorization code와 일치하는지를 확인한다

 

authorization code는 어떤 클라이언트(서버)에게 발급한거였나??? 

클라이언트 1번이었다. 그리고 그 아이디의 클라이언트 SECRET은 2번이었다.

그럼 리소스서버는 클라이언트가 전송한 authorization code와 클라이언트 ID, 클라이언트 SECRET, Redirect Url의 값과 자신이 가지고 있는 값이 완벽히 일치하는지를 확인하고 일치한다면 그 다음 단계인 액세스토큰을 발급한다.

 

OAUTH의 목적은 액세스토큰을 발급하는 것이었다. 이제부터 진짜 목적을 이루게 된다.

 

리소스서버는 이미 authorization code를 통해서 인증을 마쳤기 때문에 코드 값은 이제 지워준다. 그리고 액세스토큰을 만들고 그걸 클라이언트에게 보내준다. 클라이언트는 이 토큰을 내부적으로 저장을 해둔다.

이 액세스토큰은 무엇을 보장을 하냐면 클라이언트가 4라는 액세스토큰으로 접근을 한다면 리소스서버는 액세스토큰인 4를보고유저아이디 1번에 해당되는 사용자의 유효한 기능 B,C에대해서 권한이 열려있는 액세스 키니까 B,C 그리고 유저아이디 1에 해당되는 사용자의 정보에 대해서 액세스토큰 4를 가진 사람에게 허용을 해야겠다라고 생각한다.

 

API: Apllication Programming Interface 를 활용하여 리소스서버에 있는 정보를 활용해야한다.