OAuth 2.0
- 기업들이 만든 인증 표준
- 현재 소셜 인증 등으로 가장 널리 사용되는 방법
- 상대적으로 간편하고 안전하다.
인증과 권한 부여
- 인증 (Authentication)
- 유저 A가 자신이 A라고 주장할 때 진짜인지 아닌지를 확인해주는 절차
- 현실 세계에서는 얼굴, 목소리, 민증으로 인증할 수 있다.
- 권한 부여 = 허가 (Authorization)
- 인증 받은 사용자가 어떤 리소스에 접근이 가능한지 확인하는 절차
다양한 인증 방법
- 쿠키와 세션
- 쿠키에 세션 ID를 넣어서 인증한다.
- 토큰을 이용한 인증
- Access Token과 Refresh Token
- Access Token: 접근 권한을 인증하는 토큰
- Refresh Token: Access Token이 기한 만료되면 재발급할 때 사용함
- JWT를 사용한 인증
- 누구나 읽을 수 있지만 변조할 수 없는 인코딩된 문자열
- secret 코드를 알아야 verify 할 수 있다.
- LDAP / AD(ActiveDirectory)
- AD는 윈도우 로그인 방식
- LDAP은 AD를 일반화한 것
- 공공기관, 대기업에서 많이 사용함
OAuth2의 장점
- 인증과 권한 부여를 동시에 할 수 있다.
- 일반 사용자의 정보 유출을 막으면서 서드 파티에게 필요한 정보를 제공받을 수 있음
- 유저 <-> 서버 <-> 권한을 필요로하는 제 3자 앱
- 서버는 유저의 권한을 이용해 제 3자 앱에게 정보를 얻어온다.
ex) 이미지 출처 - 마이데이터 공공포털
- 기존의 아이디, 패스워드가 노출되지 않는다.
- 서드 파티에게 full permission이 아닌 일부 권한만 합법적으로 얻을 수 있다.
- 현재 사실상의 업계 표준으로 사용중
용어 정의
-
Resource Owner: 일반적인 사용자 (리소스 소유자)
-
client: 서비스 제공자
-
Authorization Server: 인증을 담당하는 서버 (ex: 깃헙 인증 서버)
-
Resource Server: 리소스를 가지고 있고 클라이언트에게 제공해주는 서버 (ex. 깃헙 데이터 서버)
유저(Resource Owner) <-> 서버(Client) <-> Third Party (1. Authorization server 2. Resource server)
Abstract Protocol flow
+--------+ +---------------+
| |--(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
- A: 서버는 유저에게 서드파티 권한 부여를 요청
- B: 유저에게 허가를 받음
- C: 서버는 서드파티의 Authorization Server 에게 유저에게 받은 허가로 권한 요청
- D: Autorization Server는 Access Token 으로서 권한 부여
- E: 서버는 서드파티의 Resource Server 에게 AccessToken을 가지고 정보 요청
- F: token의 진위를 판별하고 리소스 응답
Authorization Code Grant
- HTTP 리다이렉션을 통해 리소스 오너가 직접 코드를 획득하는 방식
- playground
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
- A: Client가 제공하는 Redirection URI로 유저는 브라우저를 이용해 서드 파티의 Authorization Server에 접근한다.
- B: User는 ID와 비밀번호를 입력하고 정보 제공 및 접근 권한에 동의를 해서 서드 파티에게 인증(Authenticate)을 한다.
- C: Authorization Server는 Client가 설정했던 callback URL로 리다이렉션하며 쿼리에 code를 담아 보낸다.
- D: Client는 Authorization code를 가지고 권한을 요청한다. (code가 유저에게 허가를 받았다는 Access Key(허가증!)가 된다.)
- E: Authorization Server는 Access Token을 전달해 권한을 부여한다.
Playground
-
Build the Authorization URL (Client -> Resource Owner -> Authorization Server)
GET- response_type: code
- client_id
- redirect_url: 여기에 코드를 담아서 보내주세요!
- scope: 얻고자 하는 사용자의 정보는 이거예요!
- state: CSRF 토큰이랑 비슷한 해킹 방지용
-
Verify the state parameter (Authorization Server -> Resource Owner -> Client)
리다이렉션은 브라우저에 먼저 전달되고, 브라우저가 client에게 전달되는 flow- state가 매칭되는지 확인해서 가로채기 해킹 방지
- code
-
Exchange the Authorization Code (Client -> Authorization Server)
POST- grant_type: code
- redirect_url
- client_id
- client_secret: 내가 올바른 클라이언트다!
- code: 내가 resource owner로부터 grant를 받았다.
-
Get Access Token (Authorization Server -> Client)
- access token을 받는다. (redirect_url을 요청했으면 리다이렉션도 한다)
-
client가 header에 access token을 넣고 리소스 요청을 보내면 Resource server는 토큰이 올바르고, 만료기한 이내일 때 리소스를 응답한다.
code: 유저에게 받은 허가증! 액토 주세요!
access token: Authorization 서버에게 받은 허가증! 리소스 주세요!
AccessToken & 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 +---------------+
- Refresh Token은 오직 Authorization server에만 Access Token을 재발급받기 위해 사용된다. (Resource server X)
- A: Client는 Authorization server에 인증 허가(code)를 통해 access token을 요청
- B: code가 유효하면 access token, refresh token을 발행한다.
- C: Client는 Resource server에 access token으로 리소스를 요청한다.
- D: Resource server는 리소스를 응답한다.
- E: 만료기한이 지난 access token을 보낸다.
- F: 유효하지 않은 토큰으로 에러가 발생한다.
- G: Autorization Server에 refresh token으로 새로운 토큰 발급을 요청한다.
- H: Authorization Server는 Access Token과 Refresh Token(선택)을 재발행한다.
이때 refresh token의 기간도 만료되었다면 재로그인을 통해 새로운 access token과 refresh token을 발급받아야 한다.
Ref
개발의 숲