Oath 생활코딩 필기

기본

사용자가 내 서비스에 접근해 글을 썼다면, 이런 활동을 페이스북/구글 등에 사용자의 활동 정보를 공유하고 싶다. 그러기 위해선 우리가 사용자로부터 페북 아이디, 비번을 사용자로부터 전달받아, 기억하고 있다가 페북에 접근할 때 이것을 사용할 수 있다. 사용자 입장에선 페북 비번을 처음 보는 서비스에 맡겨야 한다. 처음 보는 서비스를 믿으면 안된다. 비번을 공유하는 여러 사이트가 있기에 유출되면 큰 사고가 난다.

안전하게 우리의 서비스를 페북과 상호작용하게 하는 기술이 오오스다.
오오스를 이용하면, 우리서비스는 유저 요청에 의해 페북이 액세스 토큰을 발급해주고, 우리 서비스는 액세스 토큰을 얻어낸다.
액세스 토큰은 아이디 비번이 아니고, 회원을 식별할 수 있으며, 모든 기능이 아니라 필수적인 기능만 허용하는 토큰이다. 이토큰으로 페북에 접근해 데이터 생성 삭제 등을 할 수 있게 된다.

오오스의 세 주체

우리 서비스, User, 페북.
Resource server: 페북. 우리가 사용하고자 하는 자원을 제공하는 주체이기 때문에 리소스 서버라 불린다.
Resource Owner: 자원의 소유자이다. 페북에 올라간 자원의 소유자는 User이다. 이 User가 우리 서비스를 사용하려는 사람이기도 하다.
Client: 우리 서비스. 리소스 서버에 접근해 정보를 받아가려한다.

Authorization Server: resource서버는 데이터를 제공하는 서버인 반면에, 이 서버는 인증과 관련된 처리를 전담하는 서버이다. 공식 매뉴얼에선 분리하지만 생코에선 resource server와 합쳐 resource server라고 통칭하겠다.

Oauth 등록

1. 서버 , 오너, 클라이언트. 클라이언트가서버를이용하기위해선리소스서버의승인을사전에받아야한다. 이것을 등록이라고 한다. 서비스마다 등록 방법이 다르다. 공통부분은 client id, client secret, authorized redirect uris를 공통으로 받는다.
   client id는 우리 서비스의 식별 아이디, client secret은 비번이다. 아이디는 외부 노출될 수 있지만, 시크릿은 외부에 절대 노출되면 안된다. authorized redirect uris는 리소스 서버가 권한 부여 과정에서 우리에게 오서라이즈 코드를 전달해주는데, 이 주소로 전달해주세요라고 알려주는 것이다. 리소슷서버는 이 주소가 아닌 다른 주소에서 요청하면 무시하게 된다.

구글에선 google cloud platform에서 new project, 로 create. api&service에서 credentials, create credentials, aoath client id만들다.

resource owner의 승인

등록을 하면 리소스 서버와 클라이언트는 클라이언트 아이디, 시크릿, 리다이렉트 url이란 핵심 정보를 리소스 서버가 알게 되고, 클라이언트도 알게 된다. 클라이언트는 리다이렉트 url을 구현하고 준비해놓고 있어야한다.
리소스 서버가 갖는 기능이 4개라고 하면, 클라이언트는 리소스 서버의 일부 기능만 필요하다면, 모든 기능에 대해 인증받는 것이 아니라 최소한의 기능에 대해 인증 받는 것이 서로에게 좋다.
리소스 오너, 유저는 클라이언트에 접속을 한다. 접속 과정에서 리소스 서버를 사용해야 하는 상황이 있다. 예를 들면 페북에 글을 게시하는 등이다. 그럼 클라는 리소스 오너에게 페북으로 로그인하기 화면을 보여준다. 또는, 귀하꼐서 하시는 일은 페북의 어떤 기능이 필요한데 그 기능을 쓰려면 ㅇ니증을 거쳐야한다고 보여준다. 사용자 리소스 오너의 동의를 받아야하는데, 페북로그인 버튼이 그 동의 버튼이고, 버튼을 누르면 리소스서버에 페북/클라아이디/기능B,c/리다이렉url을 정보로 제공하게 된다.
스콥은 abc가 아니라 구글이 정한 형식에 따라 들어간다. 클라 아이디값도 부여되엉 ㅣㅆ다
리소스 오버가 리소스 서버로 저 주소로 접속하면, 리소스 서버가 오너가 현재 로긴 됐는지 안됐는지 확인한 후에, 로그인 하라고 종용하는 화면을 보여준다. 만약 로그인 성공을 한다면, 클라이언트 아이디 값과 같은 클라 아이디가 있는지 확인한다. 그리고 자신이 가진 클라 아이디에 해당하는 redirect url이 어떠한데, 접속을 시도하는 요청 리다렉 url과 같은지 다른지 확인한후에 다르면 작업을 끝낸다. 같으면 리소스 오너에게 스콥에 해당하는 권한을 클라에게 부여할지 확인하는 화면을 보여준다. 어떤 기능을 클라가 요청하는데, 확인할거냐? 화면 보여줘서 허용한다는 버튼을 누르면, 리소스 서버는 user의 아이디와 허용된 스콥을 서버에 저장한다.

Resource Server의 승인

리소스 오너에 대한 허락을 획득했으니 이제 리소스 서버가 승인해줘야한다. 리소스 서버가 바로 액세스 토큰 발급 안하고, 그 전에 절차가 하나 더 있다. 임시 비밀번호 authorization code를 리소스 서버는 리소스 오너에게 전송한다. 헤더에 location이란 값을 리다이렉션으로 줘서, 로케이션으로 주어진 주소로 이동하라고 리소스 서버가 리소스 오너의 뤱브라우저에 명령한 것이다. 서버가 오너에게 준 authorization code 3을 줬는데, 리소스 오너 사용자가 모르게 주어진 주소로 이동한다. 코드 3번에 의해 클라는 authorization code 3이란 값을 알게 된다. 이
이때 클라가 서버에게 코드 3이란 값을 전송해서 액세스 토큰 발급 전단계까지 왔다.
클라는 리소스 오너를 통하지 않고, 리소스 서버에게 직접 접속한다. 리소스 서버 토큰, grantType authorizationcode, 클라 id와 클라 시크릿을 리소스 서버에게 (클라는) 전송한다 .
(3자 간 인증에는 authorization code외에 도 3개가 있다.)
리소스 서버는 어쏘코드3번을 보고 자기가 가진 어쏘코드3번과 일치하는지 확인해ㅑㅇ한다. 어쏘코드3번은 클라 아이디 1번,ㄴ 시크릿2번, 리다이렉 url 과 일치해야한다.

그 다음 단계는 액세스 토큰을 발급하는 것이다.

액세스 토큰

지난 시간엔 서버가 클라를 승인하는 과정을 봤다. 클라가 리소스오너를 통해 어쏘코드를 받았다고 하면, 그 다음 단계로 클라는 리소스 서버에게 클라 아이디, 클라 시크릿 리다이렉 url 등을 어쏘코드와 함께 직접 전송한다.

그 다음 단계는 액세스 토크늘 발급하는 단계이다. 오오쓰의 목적이 액세스 토큰을 발급하는 일이다. 리소스 서버는 어쏘코드를 통해 인증을 했기 떄문에 어쏘코드를 지워버려야한다. 그 다음 우리 수업의 클라이막스인 리소스 서버는 액세스 토큰을 발급한다. 리소스 서버는 액세스토큰을 클라에게 응답해준다. 클라는 액세스토큰이 어떤 값이란 것을 내부적으로 저장한다. db, 파일 등에 저장한다. 그리고 액세스토큰은 클라가 액세스토큰으로 접근하면 리소스 서버는 액세스토큰 값을 보고 유저아이디 1번에 해당하는 사용자에게 b c의 유효한 기능, 스콥이 열려있는 사용자이니까, 유저 1에 대해 이 기능을 허용해야겠다고 생각하고 동작한다.

API 호출

액세스토큰을 활용해 리소스 서버를 우리가 핸들링해야한다. 조작하기 위해선 막할 수 있지 않고, 리소스 서버가 클라들에게 우리를 쓰려면 어떤 일들을 수행해야 우리를 쓸 수 있다고 알려주는 방식을 알려준다. 이것이 api이다.

클라는 리소스 서버를 호출해서 어떤 일들을 한다. 리소스 서버를 호출하는 접점에 있는 일종의 조작장치를 api라고 부른다.
예를 들어, 구글 캘린더를 리소스 서버로 제어하고 싶다고 한다. google calendar api를 검색한다. 참조 페이지에 여러 api들이 나오는ㄴ데, 구글 캘린더의 리스트 정보를 화면에 가져오고 싶다고 하면, 그 캘린더 리스트가 이것과 관련되엉 ㅣㅆ을 것이다. 이 주소를 베이스로 해서 접속하면 login required가 나온다. 이 api는 인증이 필요한데, 오오스의 액세스토큰를 이용해 가져올수있다.
액세스토큰을 구했다고 친다.
1)curl 방법을 통해서, 또는 2)주소창에 token=?토큰내용 으로 접속함으로써 할 수 있다.

리프레시 토큰

액세스토큰은 수명이 있다. 몇시간, 길게는 60일까지도 수명이 있어서, 수명이 끝나면 api에 접속했을때 데이터를 주지 않는다. 그러면 액세스토큰을 다시 발급받아야한다. 그때마다 사용자에게 그 과정을 거치게 하기 어렵다. 손쉽게 액세스토큰을 발급받을 수 있는 방법이 리프레시 토큰이다.
oauth 2.0 rfc ( rfc는 기술의 표준안이다. ) 을 검색하면, 오오스의 표준 문서이다. 목차를 보니 리프레시 토큰 설명이 있다.

a) 클라가 어쏘 그랜트를 어쏘서버에 해준다. 즉 권한을 부여한다는 것이다. 앞의 복잡한 과정을 거쳐서
b) 어쏘서버가 액세스토큰을 발급하는데, 그와 함꼐 리프레시 토큰을 함께 발급하는 경우가 많다. 이 두개의 토큰을 클라는 저장해두었다가
api호출시 액세스 토큰을 통해 리소스서버에서 자원을 가져온다 . 그런데 액세스 토큰으로 리소스 를 가져오고 있는데, 갑자기 유효하지 않은 토큰 에러가 뜬다. 이말은 즉 액세스 토큰 수명이 끝났다는 것이다 . 이러면 클라는 리프레시 토큰을 어쏘서버에게 전달하면서, 액세스 토큰을 다시 발급받는다.
경우에 따라 리프레시도 다시 발급되는 경우도 있고, 액세스 토큰만 갱신되는 경우도 있다.

끝마치며

클라 입장에서 제 3자인 리소스 서버를 통해 리소스 오너를 인증할 수 있다.
federated ..