저번에 프로젝트에서 Oauth 구현을 실패하고,,다음 프로젝트에서는 꼭 구현하리라는 다짐과 함께 생활코딩에서 Oauth 수업을 듣고 정리 해봄.
Oauth는 나의 서비스, 사용자 그리고 연동하려는 서비스가 서로 편리하게 신뢰할 수 있는 어떤 하나의 기능(?) 혹은 장치이다.
아이디 비번을 내 서비스가 가지고 있다가 연결시켜주는 방법이 있다
근데 이건 딱봐도 이렇게 유저가 서비스에 아이디비번을 맡길일도 없고
내 서비스가 아이디비번을 보관/유지가 힘들다.
그래서 아디,비번대신에 AccessToken이라는 것을 준다.
Oauth 에서는 연동할 서비스를 Resource Server 라고 부른다
유저를 자원의 소유자라는 뜻에서 Resource Owner라고 하고
우리의 서비스를 리소스 서버에서 리소스를 가져온다는 뜻에서 Client라고 한다
Resource Server외에 Authorization Server도 있는데 인증과 관련된 전담서버이다.
Client가 Resource Server를 이용하기 위해서는 사전에 등록을 해야한다.
서비스 마다 등록하는 방법이 다르지만 공통적인 방법은 Client ID, Client Secret, Authorized redirect URIs 가 필요하다.
ID는 노출되도 되지만 Secret은 노출되면 안된다.
Resource Server에 Oauth 를 위한 Client id, client Secre, redirect URL 을 만들었다고 쳤을때,
리소스서버가 가지고있는 기능이 예를들어서 A,B,C,D 이고 클라이언트가 리소스서버에서 B, C 두개의 기능이필요하다면,
최소한의 기능에 대한 인증을 받으면 된다
리소스오너는 클라이언트에 접속을하게 되고 만약에 클라이언트가 리소스서버를 사용할 일이있을때
리소스 오너에게 로그인 버튼을 누르도록 화면에 나타나도록 만들것이다.
그 링크는
http://resource.server/client_id=<client_id>&scope=<B,C>&redirect_uri=http://client/callback
이런식으로 된다.
리소스오너가 클라이언트에 어떤 리소스서버가 가지고있는 특정 기능을 쓰기 위해 접속을 저주소로하게 되면,
클라이언트가 먼저 리소스오너가 로그인되어있는지 안되어있는지 확인을 하고 안되어있으면 로그인화면을 보낸다.
리소스오너가 로그인을 성공하면 리소스서버가 그 때 클라이언트 아이디를 찾고 그 요청한 주소의 redirect_uri와 리소스서버가 가지고 있는 redirect_uri이 같은지 체크한다. 이때, redirect_uri가 다르면 바로 연결이 끊긴다.
rediret_uri가 같으면 리소스오너에게 scope(선택된 기능)에 해당하는 권한을 클라이언트에게 부여할건지 확인하는 메세지를 전송하게 된다.
허용버튼을 누르면 리소스서버에 그 정보가 전송이 되고, 리소스서버는 그 허용한 것에 대한 정보를 유저아이디와 매칭시켜서 저장한다.
이떄, 리소스서버가 바로 액세스토큰을 발급하지 않고 임시번호를 발급하는데 그게 authorization code이다.
그것을 리소스오너에게 전송한다. Location: http://client//callbakc?code=3
리소스오너의 웹브라우저는 Client에게 그 값을 전송한다
클라이언트는 액세스토큰 발급받기전 authorization code 를 받았고,
클라이언트는 리소스오너를 통하지않고 리소스서버에 다음과 같이 직접 접근한다.
http://resource.server/token?grant_type=autorization_code&code=3&redirect_uri=http://client/callback%client_id=1&client_secret=2
이때, 리소스서버는 받은 authorization code를 보고, 자기가 가지고 있는 authorization code와 같은지 확인한다. 그리고, client id, client secret도 일치하는지 확인한다. 그리고 이 정보가 모두 일치하면 다음단계로 진행하게되고 드디어 리소스서버가 액세스토큰을 발급한다
질문: 클라이언트 시크릿을 url에 포함해서 보내면 다른사람이 볼수있지 않나?
리소스서버는 authorization code는 이미 인증했기 때문에 지워버린다. 그리고 액세스토큰을 클라이언트에게 전송하고 클라이언트는 그 액세스토큰을 내부적으로 저장하고, 클라이언트가 그 액세스토큰을 가지고 접근하면 리소스서버가 그것을 보고 동작하게 된다
이제 각 언어별로 액세스토큰을 얻는 코딩을해서 액세스토큰을 발급받으면 리소스서버에서 제공하는 기능의 여러가지를 사용할수있다. 리소스서버의 서비스의 개발자를 위한 api문서를 참고해서 만들면된다.
그 이외에
액세스토큰이 만료기한이 있는데 그걸 만료했을때마다 사용자에게 인증요청을 하는 것은 번거롭기 때문에 리프레쉬토큰이라는 개념이 있다. 이건 담에 배워봐야지.