Kong Gateway는 기술적으로 무엇일까요?

 

 

Kong Gateway는 기술적으로 무엇일까요?

여러분은 Kong Gateway가 Nginx기반으로 만들어져있기 때문에 안정성과 효율성이 좋다고 알고 계실 것입니다. 하지만 정말 맞는 말일까요?

 

정확히 말하면 Kong Gateway는 Nginx에서 작동하는 Lua(Lua는 프로그래밍 언어 입니다)어플리케이션이고 lua-nginx-module에 의해 작동 되게 되어있습니다.

 

Nginx를 이 모듈과 함께 컴파일 하는 대신 콩은 lua-nginx-module을 이미 포함하고 있는 OpenResty와 함께 배포됩니다. OpenResty는 Nginx를 fork한 것이 아니라 nginx를 확장한 모듈입니다.

 

이 셋들은 런타임에 활성화 시킬 수 있고 실행시킬수 있는 곳에  Nginx에 플러그인으로 확장 할 수 있는 아키텍처로 구성 되어있습니다. 

 

이러한 이유로 Kong Gateway가 Kong 코어, 데이터베이스 추상화, 라우팅, 플러그인 관리 등에 있어 마이크로서비스 아키텍처의 대표 사례라고 생각 합니다. 플러그인은 리퀘스트 라이프사이클에 어디든 inject될 수있고 소스코드와 별도로 존재할 수 있습니다.

 

 

Kong With Keycloak

이 방식은 인증을 Keycloak에게 맡기는 방식 입니다. 클라이언트 어플리케이션을 Keycloak에 등록하고 사용자가 액세스토큰을 Keycloak에 요청 하도록 합니다. Keycloak이 발행하는 토큰은 JWT(Json Web Token)입니다. JWT는 사용자의 고유 정보(id, name, group, roles)을 포함하고 있고 인증 과정에서 필요한 issuer, time to live 등의 메타 데이터를 포함하고 있습니다.

 

액세스 토큰은 여러가지 방법으로 요청 할 수 있습니다.

Keycloak은 OAuth2 방식을 지원합니다. 액세스토큰을 온라인 또는 오프라인이 될 수 있습니다. 온라인 토큰은 웹사이트, 데스크탑앱, 모바일 앱 등 클라이언트에서 직접 요청을 하는 경우에 사용합니다.

한번 발행된 온라인 토큰은 짧은 사용 시간을 가지고 있습니다. 그래서 온라인 토큰은 이 토큰이 만료되기 전에 리프레쉬 토큰을 이용해 갱신을 해주어야 합니다.

갱신 요청을 하면 액세스 토큰은 리프레쉬 토큰과 함께 갱신 됩니다. 이 과정은 모든 유저 세션의 라이프 타임 동안 반복 됩니다.

 

오프라인 토큰은 조금 다릅니다. 오프라인 토큰은 클라이언트 어플리케이션이 사용자의 요청 없이 사용자의 정보를 백그라운드에서 사용하기 위해 사용됩니다.

오프라인 토큰은 CLI나 백그라운드 서비스 또는 모바일 어플리케이션에서 활용하기 유용합니다. The user use the client app once to claim an offline token. 오프라인 토큰 역시 짧은 사용 시간을 가지고 있지만 리프레쉬 토큰이 없습니다. 오프라인 토큰은 한달 정도의 긴 시간 동안 유효합니다. 리프레쉬 토큰은 새로운 액세스 토큰을 발급 받기 위해 백그라운드에서 사용합니다.

 

과정은 아래와 같습니다.

 

1. 사용자는 클라이언트 앱에서 sign in합니다. 사용자는 키클락이 제공하는 로그인 페이지로 리다이렉트 됩니다.
2. 로그온을 하면 키클락은 액세스 토큰과 리프레쉬 토큰을 발행 해줍니다.
3. 액세스 토큰과 리프레쉬 토큰은 다음 과정에서 사용하기 위해 클라이언트 앱에 저장 됩니다.
4. 클라이언트 어플리케이션은 Authorization http 헤더에 액세스 토큰을 넣어 요청하면 API를 액세스 할 수 있습니다. 액세스 토큰은 사용할 수 있는 시간이 짧고 만료되기 전에 리프레쉬토큰을 이용해 갱신 해야 합니다. 클라이언트 앱은 액세스 토큰이 만료 되지 않았는지 확인하고 만료되기 전에 연창 신청을 해야 합니다. 이 때 클라이언트는 Keycloak에 토큰 연장을 할 때 리프레쉬 토큰을 씁니다.
5. Kong은 액세스 토큰을 확인 합니다. 콩은 서명을 확인합니다. 토큰 발행자와 토큰의 만료 시간을 확인 합니다. 
6. 모든게 문제 없다면 Kong은 요청을 백엔드 서비스로 보냅니다. 액세스 토큰은 Authorization 헤더를 통해 전달 됩니다. 전달된 토큰은 백엔드 서비스에서 디코드 해서  세분화된 권한 부여 계층에 필요한 정보(id, group, roles)를 수집 합니다. 백엔드로 요청을 전달 할 때 Kong은 클라이언트 앱 ID를 헤더에 추가 합니다. Kong에서 추가한 클라이언트 앱 id는 사용자가 어디에서 왔는지를 인식할 때 사용할 수 있습니다.
7. 클라이언트 요청에 대한 서버의 응답은 다시 클라이언트 앱으로 전달 됩니다.



 

참고

https://docs.konghq.com/gateway-oss/

https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html