[MSA] 21. Keycloak

엔코아 플레이데이터(Encore Playdata) Backend 2기 백엔드 개발 부트캠프 (playdata.io)

백엔드 개발 부트캠프

---

1. 마이크로서비스의 보안

1. 쿠키 (Cookie)

쿠키는 브라우저에 저장되는 작은 텍스트 조각이고, 브라우저는 사용자의 컴퓨터에 설치 된 소프트웨어이다.

즉, 쿠키는 사용자가 갖고있는 정보이다.

사용자는 브라우저의 설정화면이나 개발자 도구에서 쿠키를 확인하고 수정, 삭제할 수 있다.

 

쿠키는 사용자 뿐만 아니라 제 3자가 조회하는 것도 가능하기 때문에 개인정보나 보안상 민감한 정보를 저장하는데 적합하지 않다.

때문에, 유출되어도 크게 문제가 없는 정보를 브라우저에 저장함으로써 웹사이트 이용을 편리하게 해준다.

예를 들어 특정 사이트의 환경을 저장할 때, 간단한 정보는 쿠키에 저장하여 다음 접속시에도 동일한 환경으로 사용자에게 보여준다.

 

2. 세션 (Session)

일반적으로 웹사이트에 로그인을 하면 로그인을 요구하는 해당 사이트의 기능을 사용할 수 있다. 

그런데, 아무 데이터 없이 로그인 이외의 기능을 클릭해서 서버에 요청을 하면 웹 서버는 동일한 사용자인지 알 수 없다.

그렇기 때문에 사용자가 로그인 된 사용자라는 점을 서버에 알려줘야하는데, 이를 위해 세션을 사용한다.

 

우리가 사이트에 로그인한 뒤에 해당 사이트의 서비스를 재 로그인 하지않고 사용할수 있는건 세션이 존재하기 때문이다.

즉, 서버는 로그인하면 '344asfdsfa412'  같은 형태를 가진 세션ID 를 발급하는데, 서버는 이 세션ID를 가지고 사용자를 구분하게 된다.

* 장점
사용자의 상태를 원하는 대로 통제 가능하다.
즉, 서버에서 강제로 로그아웃도 가능하다.

* 단점
메모리에 로그인 되어 있는 사용자의 상태를 보관해야 한다.

 

3. 토큰 (Token)

세션의 방식은 요청마다 함께 전송되는 세션 아이디를 바로 확인할 수 있도록, 로그인한 사용자의 아이디를 메모리에 저장하여 사용한다.

이 때, 메모리는 빠르게 확인할 수 있다는 장점은 있지만 공간의 한계가 있다.

때문에 서버에 접속하는 사용자들이 많아지면 메모리 공간이 부족해져 서버에 부하가 걸리고, 화면에 행이 걸릴 수 있다.

* 행(hang)
시스템, 네트워크, 어플리케이션이 동작하지 않고 서비스가 응답하지 않는 상태이다.
즉, 시스템 입출력에 대한 반응이 없는 상태로 시스템 운영이 불가능한 상태를 뜻한다.

 

이를 해결하기 위해 메모리 공간을 차지하는 세션 방식 대신 로그인 시 토큰을 발급한다. 이 때, 해당 서버에서 발급한 토큰은 해당 서버에서만 유효하다.

사용자는 쿠키에 발급받은 토큰을 저장하고, 이후 다시 사이트에 접속하면 서버는 해당 토큰을 통해 인증을 하여 사용자의 요청을 허가하는 방식으로 동작한다.

* 장점
상태를 메모리에 저장할 필요가 없기 때문에 메모리 공간이 확보된다.

* 단점
한번 로그인한 사용자의 상태를 토큰이 만료될 때까지 제어가 불가능하다.

 

4. OAuth2

토큰 기반의 보안 프레임워크로, 권한 부여 패턴을 설명하지만 실제 인증을 수행하는 방법은 정의하지 않는다.

이 때, 사용자는 ID 제공자 (Idp, Identity provider) 라고하는 제 3자 (3rd party) 인증 서비스로 자신을 인증할 수 있다.

사용자는 인증에 성공하면 모든 요청과 함께 전달할 토큰을 제공받고 인증 서비스에 이 토큰의 유효성을 확인한다.

---

2. OAuth 2.0

Open Authoriztion 2.0은 인증을 위한 개방형 표준 프로토콜로, 이 프로토콜을 사용하면 3rd party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식으로 동작한다.

대표적인 예로, 구글, 카카오, 페이스북, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공한다.

 

1. 그랜트 (grant)

인증 체계를 통해 REST 기반의 서비스를 보호할 수 있고, OAuth2 명세에는 네가지 그랜트 타입이 있다.

1. 비밀번호 (password)
2. 클라이언트 자격 증명 (client credential)
3. 인가 코드 (authorization code)
4. 암시적 (implicit)

 

 

2. 키클록 (keycloak)

키클록은 서비스와 어플리케이션을 위한 ID 및 엑세스 관리용 오픈소스 솔루션으로, 토큰을 발급하기 위해 사용한다.

이 때, 서비스와 어플리케이션 코딩을 전혀 혹은 거의 하지않고 쉽게 서비스와 어플리케이션을 보호하는게 목적이다.

즉, 인증을 중앙 집중화하고 SSO(Single-Sign-On) 인증을 가능하게 한다.

# Single Sign On
1회 사용자 인증으로 다수의 애플리케이션 및 웹사이트에 대한 사용자 로그인을 허용하는 인증 솔루션

실습 예제 docker-compose.yml 내 keycloak 정보

---

3. Keycloak 사용

# Roles 생성 테스트
1. localhost:8080
2. admin / admin 
3. Roles에서 ADMIN, USER 생성

ADMIN, USER 생성

# user 생성
Users - add user
illary.huaylupo
john.carnell

add user

# 생성한 user 의 password 설정
credential 탭
password1

password 설정

# 생성한 user 의 Role Mapping
ostock-admin

role mappings

# 해당 realm 을 통해 호출 가능한 endpoint 확인
OpenID Endpoint Configuration

endpoints 확인

가용한 endpoints

# client 의 token 확인
Clients - Ostock - Credentials

가용 token 확인

# 엔드포인트 호출을 통해 JSON payload 확인
http://localhost:8080/auth/realms/spmia-realm/protocol/openid-connect/token

Authorization Token 설정

JSON payload

---

4. Keycloak 을 사용한 권한 테스트

1. localhost -> keycloak 변경

# PowerToys 를 사용해 호스트파일 편집
127.0.0.1 의 DNS를 keycloak으로 설정

localhost -> keycloak

 

2. test 할 user 생성, Token 발급

# ostock-user 권한을 부여한 user 생성
ostock-user

ostock-user 권한 부여

# 생성한 user 를 사용하여 token 발급
http://keycloak:8080/auth/realms/spmia-realm/protocol/openid-connect/token

# 현재 발급받은 토큰
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJmbW1HVDFOTlJESTA3T0xJdTdoQy1VS2lWVFhFcjFXTXd6OHdfa3Q5SU9BIn0.eyJleHAiOjE2OTkzMzQ5OTEsImlhdCI6MTY5OTMzNDY5MSwianRpIjoiNWE2MjQ4MTAtMDMyOS00YTY0LTk3ZTAtMWVkMTEwZWIzZTQwIiwiaXNzIjoiaHR0cDovL2tleWNsb2FrOjgwODAvYXV0aC9yZWFsbXMvc3BtaWEtcmVhbG0iLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiZmE5MzczMTAtMTZmMy00ZDhlLThkYzctNWU2M2Y2NTFhMDM3IiwidHlwIjoiQmVhcmVyIiwiYXpwIjoib3N0b2NrIiwic2Vzc2lvbl9zdGF0ZSI6IjM0NjQ1NzUxLThiMjgtNDhlZi05NmViLTljNmVhYWNiNDE3YSIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiKiJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsib2ZmbGluZV9hY2Nlc3MiLCJkZWZhdWx0LXJvbGVzLXNwbWlhLXJlYWxtIiwidW1hX2F1dGhvcml6YXRpb24iLCJvc3RvY2stdXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7Im9zdG9jayI6eyJyb2xlcyI6WyJVU0VSIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsInByZWZlcnJlZF91c2VybmFtZSI6ImxocyJ9.d1oBPpzTR_LGQ9M0HNOn23L6vDm6LE74NhPVesIBgI54Ix4qU97a99kF0sVkDky54zU3juuHVYnpq5GRCfr2Z23c1Rv2Yxn1evOTyH6XEJ1qvuWhXdnlDky6lO_EDB8-z-MALelQSdO22AcOzGHNDzBNYISpiWzjVZAf8ZIZrhEOAL0fUIbhSXgApidhmhEb-25XiKcujF74CjMXcLisu2NPzzXMRZlAZT9Ds-DFVj_aqiItOLZ3KHWkEtCWboROOBtzMfYdFKncUG-Ecrle77WW_z84HB3C4BwxalmYHyXTMEvpORu_NrOPeduZJtnS5UYwLrsoJQJvh9JOWQwbPA

토큰 발급

 

3. 발급 받은 토큰을 통해 서비스 API 호출 - 1

# 발급 받은 토큰을 사용해 API 호출
http://localhost:8072/organization/v1/organization/e6a625cc-718b-48c2-ac76-1dfdff9a531e

발급받은 토큰을 사용해 API 호출

 

4. 발급 받은 토큰을 통해 서비스 API 호출 - 2

# 발급 받은 토큰을 사용해 API 호출
http://localhost:8072/license/v1/organization/d898a142-de44-466c-8c88-9ceb2c2429d3/license/f2a9c9d4-d2c0-44fa-97fe-724d77173c62

다른 API 호출

 

5. Access Token 을 전파하는 과정

access token 전파 과정

---

5. 68일차 후기

과거에는 session 을 사용해 user 정보를 저장하여 웹 페이지 내에서 user 정보를 유지했지만, 마이크로서비스가 도입 되고 여러 플랫폼을 함께 사용하게 되면서 session 만을 사용해서는 user 정보를 유지하기가 힘들어졌다. 

또한, 여러 유저를 저장하다보니 세션 메모리만으로는 저장하기 힘들어지는 문제가 발생했다.

 

때문에 Token 이라는 기술이 등장하게 되었고, Token을 발급할 때 JWT 형식을 사용해 어떤 플랫폼에서 사용하던 컨버팅 과정없이 사용할 수 있게 만들었다. 또한, 문자열 하나만 발급하면 되기 때문에 저장공간도 효율적으로 사용할 수 있게 되었다.