티스토리 뷰
OAuth 참여자
- Resource Owner, User(사용자)
- Service Provider(카카오, Github...)
- Client, Consumer(우리가 만드는 서비스)
OAuth 참여자의 역할
Resource Owner
- Service Provider에 계정이 존재하며,
- Client를 이용하려는 사용자.
Service Provider
-
Authorization Server(인증서버)
- User를 인증하고, Client를 인증하는 서버
-
Resource Server(리소스 서버)
- Open API를 제공하는 서버
Client
- OAuth인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션, 웹 서비스
OAuth의 흐름
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
출처: https://tools.ietf.org/html/rfc6749
OAuth의 흐름 Detail
-
Service Provider에 Client 등록하기
- Client ID
- 우리가 만드는 애플리케이션의 식별자
- Client Secret
- 우리가 만드는 애플리케이션의 비밀번호
- Authorized redirect URIs
- Authorization Code를 전달 받을 서버의 위치
- 다른 서버에서 요청하면 무시하기 위해서
- Client ID
-
Resource Owner는 Client에 로그인할 수 있는 페이지 요청
-
카카오로 로그인하기, Github로 로그인하기 등...
htttps://Service Provider.com/ ?client_id=<애플리케이션 식별자> &scope=<권한요구범위>(email...) &redirect_url=<애플리케이션서버/auth/kakao/callback>
-
-
Resource Owner는 Service Provider에 로그인 및 권한 승인
- Service Provider는 Client ID와 redirect URIs가 일치하는 지 확인한다.
- Service Provider는 Resource Owner의 권한 허용 범위를 기록한다.
-
Service Provider는 Resource Owner에게 Authorization Code(임시 비밀번호)를 전송한다.
-
Service Provider는 Resource Owner에게 redirect URI를 전송한다.
-
리다이렉트 된다
Location: 애플리케이션서버/auth/kakao/callback?code=(임시비번)
-
-
Client는 Service Provider에게 AccessToken을 발급받기 위해 요청한다.
htttps://Service Provider.com/ ?grant_type=authorization code &code=<임시비번> &client_id=<애플리케이션_식별자> &scope=<권한요구_범위>(email...) &redirect_url=<애플리케이션서버/auth/kakao/callback> &client_secret=<Client의_비번>
-
Service Provider는 Client에게 AcessToken(&RefreshToken)을 발급한다.
- AcessToken을 DB등에 저장한다.
- AcessToken은 제공자마다 만료기간이 다양하다.
-
Client는 AcessToken을 이용하여 Service Provider의 Resource Server를 이용할 수 있다.
-
Url Query에 AccessToken을 입력
GET https://www.kakao.com/drive/v2/files?access_token=<access_token>
-
Header에 AccessToken을 입력(추천)
GET /drive/v2/files HTTP/1.1 Authorization: Bearer <access_token>
-
cf. Refresh Token
-
AccessToken을 새로 발급받기위한 Token이다.
-
Service Provider마다 제공하는 방법이 다르다.
+--------+ +---------------+ | |--(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 +---------------+ Figure 2: Refreshing an Expired Access Token
출처: https://tools.ietf.org/html/rfc6749#section-1.5
정리
- OAuth를 사용자 인증을 위한 방법으로 쓸 수 있지만,
- OAuth의 주요 목적은 허가(Authorization)이다.
- OAuth2.0은 웹 애플리케이션이 아닌 애플리케이션 지원 강화
- OAuth2.0은 암호화가 필요 없음 HTTPS를 사용하고 HMAC을 사용하지 않는다.
- Access Token 갱신 OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다.
- OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.
출처
[생활코딩] https://opentutorials.org/course/3405
[Naver D2] https://d2.naver.com/helloworld/24942
[HMAC] https://hanee24.github.io/2018/04/22/hmac-authentication/
'개발 > 기술' 카테고리의 다른 글
[Gradle] Integration test 분리 (0) | 2019.12.24 |
---|---|
[네트워크] SSL/TLS (0) | 2019.12.21 |