overview
- OAuth 용어정리
- OAuth의 인증 프로세스
- Refresh Token
OAuth 용어정리
- Client: 서비스제공자
- Resource Owner: 유저
- Rsource Server: 유저가 보유한 계정의 사이트측 서버 (i.e Face book, Kakao, Google...etc)
- Authorization Server: 인증처리를 전담하는 서버 - (Rsource Server와 같은 경우도, 별개로 존재하는 경우도 있다.)
- Access token: 직접적인 id, pw의 문자열이 아닌 암호화된 비밀번호. 계정의 모든 권한이 아닌 일부기능. Client가 OAuth에게 access token을 발급받아 Rsource Server에 접근하여 Resource Owner가 실행하고자 하는 정보 혹은 기능을 제공할 수 있다.
OAuth의 인증 프로세스
1. 등록(register)과정
Client는 Rsource Server에게 승인을 받는 과정이 반드시 필요하다.
사이트마다 이 등록의 과정이 상이하지만, 모든 Register에는 아래의 세가지 값이 필요하다는 부분에서 교집합이 있다.
Clinet ID: 서비스를 식별하는 식별자이다. (외부로 노출되도 상관없다.)
Client Secret: 서비스를 식별하는 비밀번호이다. (외부로 절대 노출되어서는 안된다.)
Authorized redirect URls: Rsource Server에게권한(Authorized 코드)을 부여받기위해 필요한 주소이다. 이는 client가 사전에 Rsource Server에게 정의해두는 주소이며, Rsource Server에게 다른 URls를 통해 권한요청이 된다면 Rsource Server는 권한을 부여하지 않는다.
2. Rsource Owner의 동의과정
앞선 과정(등록)을 정상적으로 마친다면, Client와 Rsource Server는 Client ID, Client Secret, Authorized redirect URls를 서로가 공유하고 있는 상태일 것이다. 이때 Client측에서는 Authorized redirect URls에 해당하는 페이지를 구현해놓으면 된다.
https//resource.server/
?client id=1
&scope=B,C
&redirect url=https://client/callback
위의 URl에서 scope값은 Resource Server가 허용해주는 일부의 기능이다.
항상 모든 권한이 필요하지는 않으므로 필요한 기능만 scope에 기재해놓는 것이다. scope는 각 Resource Server마다 형태가 다르니, Resource Server의 홈페이지에 직접 들어가 참고하면 된다.
위의 URl로 Resource Owner가 접속한뒤 로그인이 되어있지않다면 로그인을 하도록 유도하고, 로그인이 된다면 Resource Server는
해당 URl에 있는 client id가 등록되어있는지 확인절차를 거친다. 그 뒤 Resource Owner에게 scope에 해당하는 기능을 부여하는것에
동의를 구한 뒤 동의여부는 Resource Server에게 다시 전달된다. 그 뒤 Resource Server는 해당 유저의 ID와 유저가 동의한 scope를 서버에 저장한다.
3. authorization code 발급 단계 [Rsource Server의 승인과정]
꼭 authorization code가 아니더라도 다른 방법을 통해서 access token을 발급받기전 단계를 거칠 수 있다. (총 네가지)
앞선 2단계를 거친 뒤 Resource Server는 바로 access token을 발급하지않고, 임시 비밀번호인 authorization code를 resource owner에게 전송한다.
Location : https://client/callback?code=3
- 이때 쿼리스트링에 해당하는 code=3의 부분은 authorization code값을 의미한다.
- Location은 HTTP의 헤더이며, 웹브라우저에게 https://client/callback?code=3로 이동하라는 의미이다.
- Resource Owner의 웹브라우저는 Location헤더명령에 의해 https://client/callback?code=3로 이동하게 된다.
- Resource Owner의 웹브라우저가 Location의 주소로 이동하게되면서 Client는 authorization code값을 획득한다.
https://resource.server/token?
grant_type=authorization code
&code=3
&redirect_uri=https://client/callback
&client_id=1
&client_secret=2
- client는 Resource Owner를 통하지 않고, 위와 같은 주소를 통해 Resource Server에 직접 전송하게 된다.
4. access token 발급 단계
Resource Server는 Client에게 받은 정보중 authorization code, Client Secret, Authorized redirect URls, Client id를 모두 비교해보고, 일치여부를 확인한다.
일치한다면, Resource Server와 Client는 authorization code를 삭제한다. 그리고 Resource Server는 Client에게 access token을 전송한다.
그 뒤 Client는 access token을 내부적으로 저장해놓는다.
5. API요청
Client는 Resource Server에게 API를 호출할때마다 저장해놓은 access token을 이용한다.
아래는 구글캘린더의 API호출을 정의해놓은 문서인데, <access_token>에 저장해놓은 access token을 삽입하여 요청하면된다.
- 쿼리스트링방식은 Resource Server에따라 제공될수도, 그렇지 않을수도 있다.
- Bearer방식은 보안을 위해 더욱 권장되는 방식, 표준화된 방식으로 어디에서나 사용할 수 있다.
Refresh token
'OAuth 2.0 rfc' 키워드로 검색할 것
access token은 수명이 존재한다. (짧게는 1~2시간, 길게는 90일까지도) 이렇게 수명이 다한 access token에 대해서는 API호출에 대한 응답값을 받을 수 없다. 이렇게 수명이 다할때마다 Resource Owner에게 인증과정을 다시 거치게 하는 것은 UX적으로 좋지 않기때문에 refresh token을 이용하면 된다.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+- (B)과정에서는 Resource Server에 따라 Access Token만 발급할수도 Refresh Token과 같이 발급할수도 있다.
- (F)과정은 Access Token이 만료되었기 때문에 Error가 발생한 것이다.
- (H)과정에서는 Resource Server에 따라 Access Token만 발급할수도 Refresh Token과 같이 발급할수도 있다.
아래는 구글의 rfc를 이용하는 과정이다.
