Sample

암시적 그랜프 플로우를 샘플 앱인 WMIIG 샘플 앱으로 확인해보자.

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

암시적 그랜트 플로우

WMIIG 은 사용자를 서비스 제공자의 인가 엔드 포인트로 연결함과 동시에,
리다이렉션 엔드 포인트와 scope 같은 정보를 서비스 제공자에게 전달한다.
사용자가 동의하면, 응답에 엑세스 토큰이 포함되어 전달된다.

인가 요청

사용자를 서비스 제공자의 인가 엔드 포인트로 연결한다.
OAuth 2.0 스팩은 다음과 같다.

1
2
3
4
5
6
7

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

1. response_type
   암시적 그랜트 플로우를 사용하고 있음을 나타내기 위해, token 으로 세팅한다.

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

3. redirect_uri
   서비스 제공자는 요청이 성공하면 엑세스 토큰을 이 uri 로 전달한다.

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

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

엑세스 토큰 응답

OAuth 2.0 클라이언트가 되기 위한 과정을 네 개의 단계로 정리한다.

클라이언트 애플리케이션 등록

서비스 제공자는 자신에게 요청하는 클라이언트가 누구인지 알아야한다.
그래서, 클라이언트 애플리케이션 등록이 필요하다.
애플리케이션 등록 후에 사용하게 될 정보 셋은 다음과 같다.

1. client id
   클라이언트 애플리케이션의 고유한 ID
2. client secret
   서비스 제공자에게 요청을 보낼 때, 애플리케이션의 신원을 알려주는 비밀 키
3. redirection endpoint
   서비스 제공자가 응답을 전달하기 위해 사용하는 엔드 포인트
4. authorization endpoint
   클라이언트 애플리케이션이 인가 플로우를 시작할 때 사용하는 엔드 포인트
5. token endpoint
   클라이언트 애플리케이션이 토큰 플로우를 시작할 때 사용하는 엔드 포인트

엑세스 토큰 얻기

애플리케이션을 등록했으면, 이제 엑세스 토큰을 얻어야한다.
애플리케이션에 따라 워크 플로우가 결정되는데,

1. 애플리케이션이 신뢰 애플리케이션이면, 인가 코드 그랜트 플로우를
2. 애플리케이션이 비신뢰 애플리케이션이면, 그랜트 플로우를 사용할 것이다.

그런데, 액세스 토큰이 무엇일까 ?

엑세스 토큰

하나의 리소스나 다수의 리소스에 대해, 일정 기간 동안 접근할 수 있는 권한을 캡슐화한 것이다.

시나리오

다음 시나리오로 시작하자.
사용자가 GoodApp 이라는 App 을 사용한다고 하자.
GoodApp 은 사용자의 페이스북에 등록된 친구들을 추천해줄 수 있다.

1. 사용자가 GoodApp 에게 친구 추천을 요청
2. GoodApp 은 먼저 자신을 인가해달라고 대답
3. GoodApp 은 페이스북에 대한 접근 권한을 받기 위해, 사용자가 페이스북에 로그인하도록 함
4. 페이스북은 GoodApp 이 사용자의 친구 목록에 접근하도록 허용할 것인지 질문
5. 사용자는 네 라고 대답
6. 페이스북은 GoodApp 에게 사용자의 친구 목록을 전달
7. GoodApp 은 이 친구 목록을 이용해서 사용자에게 친구 추천

Client

GoodApp 에게 사용자의 친구 목록에 접근할 수 있는 권한이 부여된 이후에는, GoodApp 과 페이스분 간 정보 교환을 위한 상호 작용이 이뤄진다.
이 상호 작용은, 클라이언트 어플리케이션의 능력에 따라 달라진다.

Untrusted Client

기밀 정보를 안전한게 저장거나 전송할 수 없는 애플리케이션이다.
예를 들면, HTML/Javascript 애플리케이션으로서 정보를 안전하게 저장하는 서버가 없는 경우이다.

Trusted Client

기밀 정보를 안전한게 저장하고 전송할 수 있는 애플리케이션이다.
예를 들면, 백엔드 서버거 존재하는 클라이언트-서버-데이터베이스 구조의 애플리케이션이다.

Grant

RPC 흐름

클라이언트가 ProductID 를 제공해서 제품 세부 사항을 조회하는 getProduct 를 호출할 때의 처리 흐름은 아래와 같다.

1. 클라이언트 프로세스는, 생성된 스텁에 있는 getProduct 함수를 호출
2. 클라이언트 스텁은, 인코딩 메세지로 HTTP POST 요청을 생성
3. HTTP 요청 메세지는 네트워크를 통해 서버 머신으로 전송
4. 서버는, 메세지 헤더를 검사해서 어떤 서비스 함수를 호출해야하는지 확인하고 메세지를 서비스 스텁에 전달
5. 서비스 스텁은, 메세지 바이트를 언어별 데이터 구조로 파싱
6. 파싱된 메세지를 사용해 서비스는, getProduct 함수를 로컬로 호출
7. 서비스 함수의 응답이 인코딩되어 클라이언트로 다시 전송
8. 메세지가 복원되어 해당 값이, 대기중인 클라이언트 프로세스로 반환

특히 위 2번의 경우, gRPC 에서는 모든 요청이 application/grpc 접두가 붙는 content-type 을 가진 HTTP POST 요청이다.
호출하는 원격 함수 (/ProductInfo/getProduct) 는 별도의 HTTP 헤더로 전송된다.

gRPC 시작에서 운영까지 <카순 인드라시리, 다네쉬 쿠루푸>

gRPC 기반 애플리케이션에서 사용되는 네 가지 통신 패턴을 정리한다.

1. Unary RPC
2. Server Streaming RPC
3. Client Streaming RPC
4. Bidirectional Streaming RPC

Unary RPC

위 방식이 Unary RPC 패턴을 따른 것이다.
클라이언트는 orderId 로 단일 요청을 보내고, 서비스는 주문 정보가 포함된 단일 응답을 돌려준다.
이 패턴을 구현해보자.

Service

우선, 프로토콜 버퍼를 사용해 아래와 같이 서비스를 정의한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

syntax = "proto3";

import "google/protobuf/wrappers.proto";

package ecommerce;

service OrderManagement {
    rpc getOrder(google.protobuf.StringValue) returns (Order);
}

message Order {
    string id = 1;
    repeated string items = 2; // 한 번 이상 반복되는 필드를 나타냄. 즉, 하나의 주문 메세지는 여러 아이템이 있을 수 있음.
    string description = 3;
    float price = 4;
    string destination = 5;
}

Server

gRPC 서비스 정의 프로토 파일을 사용해서 서버 스켈레톤 코드를 생성한 뒤에, 아래와 같이 getOrder 메서드의 로직을 구현할 수 있다.