REST API 보안 및 인가 방식

권한 인가

인증이 끝나면 다음 단계는 권한에 대한 인증, 즉 인가(Authoriation) 과정이 필요하다. 사용자가 인증을 받고 로그인을 했더라도, 해당 API를 호출할 수 있는 권한이 있는가를 확인 해야 한다.

API 인가 방식

권한 인가(Authorization) 방식에는 여러 가지 방식이 있는데, 대표적인 방식 몇 가지만 보면 가장 일반적인 권한 인증 방식으로는 사용자의 역할을 기반으로 하는 RBAC (Role Based Access Control) 이라는 방식이 있다. 이 방식은 정해진 연결에 권한을 연결해놓고, 이 역할을 가진 사용자에게 해당 권한을 부여하는 것이다.

• 이러한 API 권한 인가 체크는 인증(Authentication)이 끝난 후에 인가에 사용된 API Access Token을 이용하여 사용자 정보를 조회하고, 사용자 정보에 연관된 정보(Permission이나 Role 정보)를 받아서 이 권한 정보를 기반으로 API 사용 권한을 인가하는 방법을 사용한다.

• 이러한 권한 검증을 이용하여 API Access Token 으로 사용자를 찾고 사용자에게 할당된 역할이나 Access Control을 받아서 API 인증을 처리할 수 있다.

• 인가 방식의 종류로는 아래 두 가지 방식이 있다.

RBAC(Role Based Access Control)

일반 사용자 : 사용자 관리, 게시물 관리, 회원 가입 승인
마스터 관리자 : 카폐 게시판, 관리, 메뉴 관리, 사용자 관리, 게시물 관리, 회원 가입 승인

• 위와 같은 권한을 만들고, 사용자에게 마스터 관리자라는 역할을 부여하면, 사용자는 카페 게시판 관리, 사용자 관리, 게시물 관리, 회원 가입 승인 등의 권한을 가지게 된다.

• 이렇게 권한 부여의 대상이 되는 사용자나 그룹을 Object라고 하고 개별 권한을 Permission 이라고 정의하며 사용자의 역할을 Role 이라고 정의한다.

• RBAC는 이 Role에 권한을 맵핑한 다음 Object에 이 Role을 부여하는 방식으로, 많은 권한 인가는 사용자 역할을 기반으로 하기 때문에 사용하기 쉽다.

ACL(Access Control List)

• RBAC 방식이 권한을 Role이라는 중간 매개체를 통해서 사용자에게 부여하는데 반해서 ACL 방식은 사용자 (또는 그룹과 같은 권한의 부여 대상) 에게 직접 권한을 부여하는 방식이다.

• 사용자에게 직접 카페 게시판 관리, 메뉴 관리, 게시물 관리, 회원 가입 승인 권한을 부여하는 방식이 대표적인 ACL의 예이다.

API 권한 인가 처리 위치

• API에 대한 권한 인가 처리는 여러가지 계층에서 처리할 수 있다. 권한 인가는 API를 호출하는 쪽인 클라이언트, API를 실행하는 API 서버, 그리고 API에 대한 중간 길목 역할을 하는 게이트웨이 등 3군데에서 처리할 수 있으며 근래에는 API 서버쪽에서 처리하는 것이 가장 일반적이다.

• 권한 인가 위치는 아래와 같은 경우가 있다.

클라이언트에 대한 API 권한 인가 처리

• API를 호출하는 클라이언트 쪽에서 사용자의 권한에 따라서 API를 호출하는 방식인데, 이 방식은 클라이언트가 신뢰할 수 있는 경우에만 사용할 수 있다.

• 이 방식은 기존에 웹 UX 로직이 서버에 배치된 형태 (스트러츠나 스프링 MVC와 같은 웹 레이어가 있는 경우)에 주로 사용했다.

• 앞의 사용자 API를 예로 들어보면 웹 애플리케이션에서 사용자 로그인 정보(세션 정보와 같은)를 보고 사용자 권한을 조회하고 API를 호출하는 방식이다.

• 사용자 세션에서 사용자 ID와 역할을 본 후에, 역할이 일반 사용자일 경우 세션 내의 사용자 ID와 조회하고자 하는 사용자 ID가 일치하는 경우에만 API를 호출하는 방식이다.

• 이러한 구조를 사용할 때, 모바일 디바이스 등에 제공하는 API는 사용자 역할을 하는 API와 같이 별도의 권한 인가가 필요 없는 API를 호출하는 구조를 갖는다.

게이트웨이에 의한 권한 인가 처리

• 이러한 권한 인가는 모바일 클라이언트, 자바스크립트 기반의 웹 클라이언트 등 다양한 클라이언트가 지원됨에 따라서 점차 서버쪽으로 이동하게 되었는데, 특히 자바 스크립트 클라이언트는 클라이언트에서 권한에 대한 인가는 의미가 없어서 어쩔 수 없이 서버 쪽에서 권한 인가 처리를 할 수 밖에 없게 된다.

• 만약에 자바스크립트에 권한 인가 로직을 넣은 경우, 브라우저의 디버거로 코드 수정이 가능하기 때문에 권한 처리 로직을 우회할 수도 있고, 또한 API 포맷만 안다면 직접 API 서버로 호출해서 권한 인가 없이 API를 사용할 수 있다.

• 서버에서 권한을 처리하는 방법은 API 호출의 길목이 되는 게이트웨이나 API 비즈니스 로직 두 군데서 처리할 수 있다. API Gateway에 의한 권한 처리를 쉽지 않기 때문에 API 서머에서 권한 처리를 하는 것이 일반적이다.

• API 호출이 들어오면 API 토큰 관리 정보를 이용해서, API Access Token을 사용자 정보와 권한 정보로 변환하고 접근하고자 하는 API에 대해서 권한 인가 처리를 한다. 이때는 API 별로 API에 접근하고자 하는데 필요한 권한을 확인해야한다.

• 예를 들어 HTTP GET /users/{:id}의 API를 예로 들면 이 URL에 대한 API를 호출하려면 일반 사용자 권한을 가진 사용자는 호출하는 사용자 ID와 URL상의 {id}가 일치할 떄, 호출을 허용하고, 같지 않을 때는 호출을 거절 해야한다.

• 그러나 이러한 API Gateway에서의 권한 인가는 쉽지 않은데, 앞의 /users/{id} API의 경우에는 사용자 ID가 URL에 들어가 있기 때문에 API Access Token과 맵핑되는 사용자 ID와 그에 대한 권한을 통해서 API 접근 권한을 통제할 수 있다. 하지만 API에 따라서 사용자 아이디나 권한 인증에 필요한 정보가 HTTP 바디에 JSON 형태나 HTTP 헤더 등에 들어가 있는 경우 일일히 메시지 포맷에 따라 별도의 권한 로직을 게이트 웨이 단에서 구현해야 하는 부담이 있고, 권한 통제를 위해서 HTTP 메시지 전체를 일일히 파싱해야하는 오버로드가 발생하기 때문에 공통 필드 등으로 API 권한 처리를 하지 않을 때에는 사용하기 어렵다.

서버에 의한 API 권한 인가 처리

• 가장 일반적이고 보편적인 방법은 API 요청을 처리하는 API서버의 비즈니스 로직 단에서 권한 처리를 하는 것이다.

• 이 방식은 앞에서 언급한 API Gateway 방식과 비교했을 때, 각 비즈니스 로직에서 API 별로 권한 인가 로직을 구현하기 용이하다.

• 이 경우에는 권한 인가에 필요한 필드들을, API Gateway에서 변환해서 API 서버로 전달해줌으로써 구현을 간략하게 할 수 있는데, 다음 그림과 같이 API 클라이언트가 API Access Token을 이용해서 API를 호출 했을 경우, API Gateway가 이 Access Token을 권한 인가에 필요한 사용자 아이디, 롤 등으로 변환해서 API 서버에 전달해주게 되면, 각 비즈니스 로직은 API 권한 인가에 필요한 사용자 정보를 별도의 데이터베이스에서 찾지 않고도 이 헤더의 내용만을 이용해서 API 권한 인가 처리를 할 수 있게 된다.

참고 문헌

• 대용량 아키텍처와 성능 튜닝