05.API Gateway 인증
API Gateway의 목적
- MSA로 서비스를 만들 때 가장 중요한 요소 중 하나로, 서버 앞에서 이들의 기능을 적절하게 라우팅해주기 위해 사용된다.
- 일반적으로 JSON / REST 기반으로 구성되어 최소한의 기능만 하도록 한다
인증 및 인가
- 인증
- 유저의 정보를 확인, 유저가 누구인가(회원가입, 로그인)
- API를 호출하는 클라이언트의 신분 확인(회원인가 비회원인가)
- 인가
- 유저의 권한을 확인(역할, 접근 가능 범위)
- 클라이언트가 해당 API를 호출해도 되는지의 권한 확인(관리자인가 사용자인가, 어디까지 정보를 호출할 수 있는가)
API 토큰
- 사용자의 인증 및 인가를 간단히 하기위해 API 토큰을 사용한다.
- 인증 및 인가 확인 절차가 완료가 되면 사용자가 API를 호출할 수 있는 권한이 있는 토큰을 발급한다.
- API 서버에서는 발급된 토큰을 통해 사용자의 신분과 권한을 확인하여 API 호출에 대한 허가를 결정한다
토큰 발급
- 클라이언트 인증 방식은 id/pw , 공인인증서 , OTP 등 다양하다
- API GW는 인증에 대한 요청을 인증서버로 보낸다. 인증 서버는 단순히 인증만 처리하며, 토큰의 발급은 API GW에서 진행한다. 이를 통해 다양한 인증 방식을 적용하고 이를 선택적으로 사용하는 것이 가능하다
- 인증이 성공하면 해당 결과를 API GW로 전송한다
- API GW에서는 결과에 따라 토큰을 발급한다.
- 1.. 서버에 권한 내용을 저장하는 토큰
- 일련의 문자열로 구성된 OAuth 기반의 토큰의 경우에는 API GW 내부에 클라이언트와 발급된 토큰의 정보를 아래와 같이 데이터베이스 형태로 저장한다.
| token | user | role |
|---|---|---|
| abc1234 | Alice | admin |
| xyz789 | Bob | user |
- 이러한 서버 기반의 토큰 방식의 특징
- 토큰의 정보를 저장하기 위한 공간이 별도로 필요하여 노력과 비용이 추가된다
- 전달받은 토큰의 정보를 확인하는 추가작업이 빈번하기 때문에, 일반적으로 이를 빠르게 처리하기 위해 메모리 기반의 고속 스토리지(redis, memcached 등)을 사용한다.
- 서버에 토큰의 정보가 저장되기 때문에 비교적 안전하게 관리될 수 있다.
- 토큰은 단순히 문자열로만 구성되며 대부분의 정보는 데이터베이스에서 관리되기 때문에, 많은 정보를 저장하고 이를 수정하기에 용이하다
- 2.. 토큰 자체에 권한 내용을 저장(클레임)
- 토큰 내부에 사용자의 정보를 포함(Claim)하는 토큰(JWT, SAML 등)인 경우 토큰 자체에 권한 정보가 저장된다.
- 특징
- 별도의 저장소가 필요없기 때문에 노력이나 비용적인 면에서 효율적이다
- 토큰 자체에 클레임이라는 단위로 이루어진 정보들이 들어가기 때문에, 많은 정보를 넣을 경우 토큰의 길이가 길어져 양을 제한해야 한다
- 토큰이 한 번 발급되면 이를 수정하는 것이 어렵다(재발급이 더 편하다)
- 토큰에 정보들이 모두 들어가 있기 때문에 보안적으로 취약할 수 있다. 이를 막기 위해 비교적 짧은 유효기간을 둬서 사용을 제한해야 한다
토큰 인증
- API GW는 발급된 토큰을 검증해서 API 호출의 승인 여부를 결정한다.
- 1.. 서버에 토큰 정보를 저장한 경우
- API 호출을 요청할 때마다 토큰에 해당하는 정보를 서버에서 조회한 후, 이를 비교하여 API 호출 여부를 결정한다
- 2.. 클레임 기반인 경우
- 토큰 자체에 정보들이 있기 때문에, 서버에서의 확인 작업이 별도로 필요하지 않다
- 3.. 기타
- 모든 서버가 외부로만 구성되지는 않는다
- 금융권의 경우 서버 구성은 내부서버가 많고, 이러한 상황에서 토큰 방식을 적용하여 불필요한 인증과정을 추가할 필요는 없다
- 대체로 이런 경우에는 별도의 인증 서비스를 거치지 않고, 외부망과 내부망 사이에서의 보안을 더 강화하는 경우가 많다
- 외부 서버끼리의 통신에서도 토큰 사용대신에 SSL 기반의 높은 보안성을 갖는 인증 방식을 사용하는 경우도 많다.
토큰 인가
- 역할에 따라 권한을 부여하는 방식이 많이 사용된다.
- 1.. 개별 권한을 직접 토큰에 부여한 경우
- 이렇게 하면 토큰 별로 세밀하게 권한을 부여할 수 있다는 장점이 있다.
- 하지만 권한이 많아질수록 이를 관리하는 것이 복잡해질 수 있다.
- 각 권한 별로 요청하는 API를 만들어 놓기도 한다
- 2.. 역할별로 권한을 토큰에 부여한 경우
- 역할 별로 권한을 미리 분류해서 해당 역할을 토큰에 부여하는 방식
- 이를 RBAC(Role Based Access Control)이라고 부른다
- 장점은 관리 포인트가 줄어든다. 권한의 갯수가 많아질수록 역할별로 공통되게 부여되는 권한을 미리 구분해서 처리하기 때문이다
- 단점은 세세한 권한 관리는 어렵다
캐시(Cache)를 활용하기
- 발급된 토큰은 일반적으로 잘 변하지 않는 성격이라고 볼 수 있다.
- 결국 같은 토큰을 반복해서 인증에 사용하는 것이라고 생각할 수 있다. 따라서 캐시를 사용하면 효율적으로 인증 과정을 처리할 수 있다
- 왜냐하면 불필요한 통신과정이 생략되기 때문에 속도가 빠르고, 인증 서비스와 통신하는 횟수가 줄어들기 때문에 서버와 통신하면서 발생할 수 있는 장애빈도도 줄어들 것이다.
- 하지만 실제로 토큰이 변경되는 상황(신규 또는 재발급)에는 캐시된 내역이 오류를 발생시킬 수 있다. 이를 위해서 캐시 또한 적절한 만료시간을 적용해야 한다
2중화의 필요성
- API GW가 모든 서비스를 전달하는 통로이기 때문에 장애가 발생할 시 치명적인 단일 실패점(SPOF : Single Point Of Failure)가 될 수 있다.
- 그렇기 때문에 API GW는 반드시 2중화를 해놓는 것이 좋다