CMAK 를 어떤 목적으로 사용하는지 정리하고, 설치하고 실행해본다.

CMAK

CMAK (Cluster Manager for Apache Kafka) 는, 야후에서 만든 Kafka Cluster 를 managing 하기 위한 tool 이다. CMAK 를 이용해서 다음과 같은 것들을 할 수 있다.

1. Create, Delete topic
2. Add partitions to existing topic
3. Update config for existing topic
4. Inspection of cluster state
5. …

Requirements

Kafka package 설치하고, Zookeeper 를 아래와 같이 start 한다.

1

bin/zookeeper-server-start.sh config/zookeeper.properties

Kafka 를 아래와 같이 start 한다.

1

bin/kafka-server-start.sh config/server01.properties

Proxy Pattern 에 대해 정리한다.

Proxy Server

프록시 패턴에 대해 정리하기 전에, 프록시 서버가 무엇인지 보자.

프록시의 사전적 의미는 “대리, 대리권, 대리 투표, 대리인” 이다.
프록시 서버는, 위키에 따르면 다음과 같다.

프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.
서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 ‘프록시’, 그 중계 기능을 하는 것을 ‘프록시 서버’ 라고 부른다.

정리하면 프로시 서버는,

1. 클라이언트의 요청을 서버에게 대신 전달하고
2. 서버의 응답을 클라이언트에게 대신 전달한다.

Proxy Pattern

그렇다면, 프록시 패턴은 무엇일까 ? 위키에 따르면 다음과 같다.

액세스 토큰이 만료되면 어떻게 해야할까 ?

Refresh Token Workflow

서비스 제공자가 Refresh Token Workflow 를 지원한다면,
엑세스 토큰 요청이 대한 응답에 access_token 뿐만 아니라 refresh_token 값도 포함되어있다.
응답에 refresh_token 이 포함되어 있지 않으면 Refresh Token Workflow 를 지원하지 않는 것이다.

리프레시 요청

리프레시 토큰을 이용해서 엑세스 토큰을 요청하려면,
서비스 제공자의 토큰 엔드 포인트로 POST 요청해야한다.

1
2
3
4
5
6

POST /token HTTP/1.1
HOST: server.example.com
Authorization: BASIC [ENCODED_CLIENT_CREDENTIALS]
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=[REFRESH_TOKEN]

1. grant_type
   리프레시 토큰을 이용해서 새로운 액세스 토큰을 요청한다는 것을 나태내기 위해
   refresh_token 이어야한다.

2. scope
   원래의 엑세스 토큰보다 더 큰 접근 범위를 지정해서 요청할 수 없다.
   즉, 갱신된 엑세스 토큰은 이전과 동일하거나 작은 접근 권한 범위를 가져야한다.

엑세스 토큰 응답

엑세스 토큰 요청이 성공하면 다음과 같은 파라미터가 전달된다.

1. access_token
   얻고자 했던 엑세스 토큰이다.

2. token_type
   전달되는 토큰의 유형이다.
   대부분 bearer 토큰이다.

3. expired_in
   토큰의 유효기간이다.

4. refresh_token
   엑세스 토큰이 만료되면 엑세스 토큰을 갱신하기 위해 사용되는 토큰이다.

5. scope
   인가된 접근 범위이다.

암시적 그랜트 플로우나 인가 코드 그랜트 플로우를 이용해서,
서비스 제공자에게 엑세스 토큰을 요청할 수 있게 되었다.
이제, 엑세스 토큰을 이용해서 서비스 제공자가 제공하는 API 를 호출할 차례이다.

엑세스 토큰 이용해서 API 호출

API 를 호출할 때 엑세스 토큰을 전달하는 방법으로는 세 가지가 있다.

1. 인가 요청 Header Field 에 담아서 전달
2. 인코딩된 Form 의 Parameter 로 전달
3. URI Query Parameter 로 전달

인가 요청 Header Field 에 담아서 전달

OAuth 2.0 스팩에서 권장하는 방식이다.
HTTP 요청의 Authorization Header 에 엑세스 토큰을 담아서 서비스 제공자에게 전달하는 것이다.
엑세스 토큰을 요청하기 위해 사용된, basic authorization 방법과 유사하다.
차이점은, Basic 이 아니라 Bearer 가 사용된다는 것이다.

1
2
3

GET /resource HTTP/1.1
HOST: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

인코딩된 Form 의 Parameter 로 전달

Authorization Header Field 를 사용하지 않고 HTTP Header 의 다른 Field 를 사용하는 것이다.
GET 아닌 POST 요청을 한다는 점이 중요하다.

1
2
3
4
5

POST /resource HTTP/1.1
HOST: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

Sample

인가 코드 그랜프 플로우를 샘플 앱인 WMIIG 샘플 앱으로 확인해보자.

1. 사용자 : WMIIG 로 접속해서, 인포그래픽을 보려고 한다.
2. WMIIG : 당신의 프로파일과 당신이 작성한 글에 접속해야 하므로, 여기서 인가해달라고 요청한다. (페이스북으로 연결)
3. 페이스북 : WMIIG 이 사용자의 프로파일과 작성한 글에 접근하는 것을 허용할지 사용자에게 물어본다.
4. 페이스북 : 사용자가 허락했으면, WMIIG 에게 사용자의 프로파일과 글에 접근하는 데 사용할 수 있는 엑세스 토큰과 교환 가능한 인가 코드를 전달한다.
5. WMIIG : 페이스북으로부터 받은 인가 코드를 이용해서 사용자의 페이스북 프로파일과 글에 접근할 수 있는 엑세스 토큰을 요청한다.
6. 페이스북 : 전달된 인가 코드를 확인하여, WMIIG 에게 엑세스 토큰을 전달한다.
7. WMIIG : 페이스북으로부터 받은 엑세스 토큰을 이용해서 페이스북에게 사용자의 프로파일과 글을 요청한다.
8. 페이스북 : 전달된 엑세스 토큰을 확인한 후, 사용자의 프로파일과 글을 전달한다.

인가 코드 그랜트 플로우

1. 사용자 동의 화면에서 사용자가 동의를 하면
2. 리다이렉션 엔드포인트로 인가 코드가 전달되고
3. 인가 코드를 엑세스 토큰과 교환한다.

인가 요청

사용자를 서비스 제공자의 인가 엔드 포인트로 연결한다.
OAuth 2.0 스팩은 다음과 같다.
response_type 이 code 이 경우만 제외하면, 암시적 그랜트 플로우와 동일하다.

1
2
3
4
5
6
7

GET /authorize?
  response_type=code&
  client_id=[CLIENT_ID]&
  redirect_uri=[REDIRECT_URI]&
  scope=[SCOPE]&
  state=[STATE] HTTP/1.1
HOST: server.example.com

1. response_type
   인가 코드 그랜트 플로우를 사용하고 있음을 나타내기 위해, code 로 세팅한다.

2. client_id
   클라이언트 등록 과정에서 제공된 클라이언트 고유 아이디이다.

3. redirect_uri
   서비스 제공자는 요청이 성공하면 인가 코드가 이 uri 로 전달한다.

4. scope
   클라이언트가 요청하는 접근 권한의 범위이다.
   각 범위는 공백 문자로 구분된다.

5. state
   클라이언트의 요청과 그에 따른 콜백 간의 상태를 유지하기 위해 사용된다.
   클라이언트가 서비스 제공자에게 전달하면 서비스 제공자는 이 값을 다시 응답에 포함해서 전달한다.