Resource Owner사용자 / Client타겟 서비스(만들 수 있는 그냥 서비스) / Resource Server 서드파티로 데이터를 가지고 있는 서버(google) / Authorization Server(인증 역할을 하는 서버)
Resource Server와 Authorization Server는 사실 거의 같은 느낌으로 받아들여도 문제 없음
둘다 큰 회사에서 처리를 해주기에
register과정.
만들었을 때, 서비스가 큰 회사에 자기가 oauth를 쓸거라는 것을 알려주는 과정
ClientID 외부에 노출되도 괜찮은 서비스에 할당되는 ID
Client Secret 외부에 노출되면 안 되는 client id에 해당하는 secret
Authorized redirect URIs 권한 부여를 하고, Auth code를 줄 때 어떤 주소로 전달해 주세요 라고 하는 것
보통 api의 credintials 를 이용해서 oauth를 하게 됨.
클라이언트가 사용자에게 보여줄 버튼에는
쿼리로 버튼 옵션을 다 받아줘야 함
https://resource.server/?client_id=1&scope=b,c&redirect_uri=http://redirect/calback
같은 느낌으로 되어 있는 버튼을 클릭하는 과정이 있으면 됨.
이러면 리소스 오너가 로그인이 되어 있는지 여부를 resource server가 받고, 로그인을 시키고, CLIENTID가 있는지,SCOPE에 해당하는게 있는지 확인,uri 가 지금 원하는 redirect_uri에 맞는지 확인.
그 이후에 확인 리소스 오너에게 클라이언트가 요청하고 있는데, 허용할 것인지를 확인하고, 리소스 서버가 그거를 받고, 임시 비밀번호를 위한 auth code를 만들어 냄. resource 서버가 resource오너에게 전송을 함. 리소스 서버가 리소스 오너에게 특정 uri로 이동을 시킴.
그 주소가 register 당시에 등록을 했던 redirect URI 에 추가적으로 쿼리나 파라미터로 authorization code를 붙혀줌.
그러면 client가 code가 맞는지 resource 서버에 접속을 함.
이때 client id, redirect uri, code, client secret같은 것들을 다 모아서 보냄.
그러면 확인이 되고, authorization code를 지워버림. 이러면 access token을 client에게 응답을 해줌. 그러면 내부적으로 access 토큰을 내부적으로 저장을 함.
이때 보장하는 것은 client가 4라는 access token으로 접근을 하면, userid 1에 해당하는 scope b,c에 해당하고, access token 4를 가진 사람에게 처리를 해주면 되겠다는 것을 알 수 있음
토큰으로 모아서 서버에게 전송한다.
리소스 서버를 조작하는 과정이 이제 api를 사용해야 함.
google calendar api 같은 것들을 보면 어떻게 처리하는 지 설정할 수 있음
oauth 에 토큰을 이용해서 리소스 서버를 조작하기 위한 실질적인 방법으로는 url 뒤에 ? 토큰 을 붙혀서 쿼리를 보낼 수도 있고, 헤더로 토큰을 붙혀서 쓸 수도 있음.
헤더로 토큰을 붙혀서 사용하는 방법이 훨씬 많이 쓰이긴 함.
accesstoken을 다시 발급 받기 위해 다시 인증을 하기 귀찮은 경우에 refresh token을 받음
oauth 2.0 rfc
rfc라고 하는 것은 인터넷 표준
만약 토큰 에러가 딱 뜨면, 이거를 authorization서버에 refresh token을 보내고, 재발급을 받는 과정을 거침
이런 것들을 다 알아서 해주는 것이 passport다
갓이다. 라이브러리를 잘 활용하자.
토큰이라고 하는 거에서 post방식으로 처리를 하고, client id, secret, refresh token, grant type이라는 것을 보내면 새로운 access token을 보내고, 유효기간을 담아서 알아서 보내줌
oauth의 제3자와 서버의 인증으로 로그인 과정을 대체하는 것. 우리의 목적은 oauth로 api를 제어하는 것
