REST API 보안_인가(Authorization)

2019/06/07 - [프로그래밍 노트/WEB] - REST API 보안_인증(Authentication)

2019/05/30 - [프로그래밍 노트/WEB] - REST API 보안_1

※ 모든 REST API보안관련된 내용은 거의 내용이 비슷하다고 봐도 무방할정도로 조대협님의 블로그를 참고하였다. 쉽고 자세하게 설명이되 있어서 .. 블로그 구독을 눌렀다. (조대협님의 블로그)

인증이 끝나면 인가(Authorization)과정이 필요하다.
사용자가 인증을 받고 로그인을 했더라도 해당 API를 사용할 수 있는 권한이 있는지 체크하는 과정이 필요하다.
예를 들면 일반사용자가 사용자를 삭제하는 API를 호출할 수 있게 되면 큰일나기 때문에 (관리자만 사용해야함) 인증을 통해서 시스템 내의 사용자임을 확인 받았지만, API 호출을 하기 위해서 적절한 권한이 있는지 검증해야 한다.

1.API 인가 방식

대표적으로 2가지 방식이 존재한다.

1-1. RBAC(Role Based Access Control)

사용자의 역할(Role)을 기반으로 하는 RBAC방식이 있다.
정해진 Role에 권한을 연결해 놓고, 이 Role을 가지고 있는 사용자에게 해당 권한을 부여하는 것이다.

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

같은 권한을 만든 후, Terry에게 마스터 관리자라는 Role을 부여하면 Terry는 마스터관리자가 갖는 권한을 모두 갖게 된다.

이렇게 권한 부여의 대상이 되는 사용자나 그룹을 Object, 각 개별 권한을 Permission, 사용자의 역할을 Role이라고 정의한다.
RABC는 Role에 권한을 맵핑한 다음 Object에 Role을 부여하는 방식이다. 많은 권한 인가는 사용자 역할을 기반으로 하기 때문에, 사용하기가 용이하다.

RBAC

1-2. ACL(Access Control List)

RABC방식은 권한(Role)이라는 중간 매개체를 통해서 사용자에게 부여하는데 반해서, ACL 방식은 사용자에게 직접 권한을 부여하는 방식이다.
사용자 Terry에 직접 "게시판 관리, 메뉴 관리, 사용자 관리, 게시물 관리, 회원 가입 승인" 권한을 부여하는 방식이 ACL 방식이다.

ACL

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

2.API 권한 인가 처리 위치

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

2-1. 클라이언트에 의한 API 권한 인가 처리

조대협님의 블로그 참고

2-2. GateWay에 의한 권한 인가 처리

이뤄한 권한 인가는 모바일 클라이언트, 자바스크립트 기반의 웹 클라이언트 등 다양한 클라이언트가 지원됨에 따라 점차 서버쪽으로 이동하기 시작했는데, 특히 자바스크립트 클라이언트의 경우 클라이언트에서 권한에 대한 인가는 의미가 없기 때문에 어쩔 수 없이 서버 쪽에 권한 인가 처리를 할 수 밖에 없게 된다.
만약에 자바스크립트에 권한 인가 로직을 넣을 경우, 자바 스크립트의 경우 브라우져의 디버거등으로 코드 수정이 가능하기 때문에 권한 로직을 우회할 수 있고 또한 API 포멧만 안다면 직접 API를 서버로 호출해서 권한 인가 없이 API를 사용할 수 있다.
서버에서 권한을 처리하는 방법은 API 호출의 길목이 되는 Gateway나 API 비즈니스 로직 두군데서 처리가 가능하다. API Gateway에 의한 권한 처리는 구현이 쉽지 않아 API 서버에서 권한 처리를 하는 것이 일반적이다.

Gateway Authorization

API Gateway에서의 권한 인가는 쉽지가 않은데, /users/{id} 가 GET 요청일 경우, 일반 사용자 권한을 가지고 있는 사용자의 경우에는 호출하는 사용자 id와 URL 상의 {id}가 일치할 때 호출을 허용하고, 같지 않을 때는 호출을 불허해야 한다. 만약 사용자가 관리자 권한을 가지고 있을 경우에는 호출하는 사용자 id와 URL 상의 {id}가 일치하지 않더라도 호출을 허용해야 한다.
위의 /users/{id} API의 경우에는 사용자 id가 URL에 들어가 있기 때문에, API access token과 맵핑되는 사용자 ID와 그에 대한 권한을 통해서 API 접근 권한을 통제할 수 있지만, API에 따라서 사용자 id나 권한 인증에 필요한 정보가 HTTP Body에 json 형태나 HTTP Header 등에 들어가 있는 경우, 일일이 메세지 포맷에 따라서 별도의 권한 통제 로직을 gateway 단에서 구현해야 하는 부담이 있고, 권한 통제를 위해서 HTTP 메세지 전체를 일일이 파싱해야 하는 오버로드가 발생하기 때문에, 공통 필드등으로 API 권한 처리를 하지 않는 경우에는 사용하기가 어려운 부분이다.

2-3. 서버에 의한 API 권한 인가 처리

가장 일반적이고 보편적인 방법은 API 요청을 처리하는 API 서버의 비즈니스 로직단에서 권한 처리를 하는 방식이다.
이 방식은 앞에서 언급한 API Gateway방식과 비교했을 때, 각 비즈니스 로직에서 API 메시지를 각각 파싱하기 때문에 API 별로 권한 인가 로직을 구현하기가 용이하다.
이 경우에는 권한 인가에 필요한 필드들을 API Gateway에서 변환해서 API 서버로 전달해줌으로써 구현을 간략하게 할 수 있는데, 아래 그림과 같이 API 클라이언트가 API Access Token을 이용해서 API를 호출했을 경우, API Gateway가 이 Access Token을 권한 인가에 필요한 사용자 ID, ROLE 등으로 변환해서 API 서버에게 전달해주게 되면, 각 비즈니스 로직은 API 권한 인가에 필요한 사용자 정보등을 별도로 데이터베이스를 뒤지지 않고 이 헤더의 내용만을 이용해서 API 권한 인가 처리를 할 수 있게 된다.

Server API Authorization