AAA는 컴퓨터 네트워크를 제어하고 추적하기 위한 framework이며, 각각 Authentication, Authorization, Accounting를 의미합니다.
Authentication과 Authorization은 제어의 목적을 Accounting은 추적의 목적을 가지고 있습니다.
이 글에서는 AAA 중 인증(Authentication)과 인가(Authrization)에 대해서 알아보고, Web에서 실제로 사용되는 방법은 어떠한 것이 있는지 알아보겠습니다.
인증? 인가?
인증과 인가에 대해서 간단히 이야기하면 아래와 같습니다.
- 인증(Authentication) : Who are you?
- 인가(Authorization) : What can you do?
인증은 유저가 제한된 시스템에 접속을 시도할 때 자격증명(credentials)을 하는 과정입니다. 한편, 인가는 유저가 인증된 시스템에서 특정 행동을 할 수 있는지 확인하는 과정입니다.
예를들면, 배달의 민족 서비스를 이용하는 가게 사장님이 악의적인 리뷰를 지우는 상황을 가정 해봅시다. 배달의 민족 시스템에 로그인하여 악의적인 리뷰를 지울려고 했지만 실패할 것 입니다. 여기서 배달의 민족 시스템에 로그인하는 행위를 인증, 악의적인 리뷰를 지우기 위해서 권한을 확인하는 행위를 인가라고 합니다.
여기서, 배달의 민족 서비스에 인증할 수 있는 다양한 방법이 있습니다. 웹어서는 인증과 인가를 위한 다양한 방법들이 존재합니다. 각각의 장단점을 알아보겠습니다. ??
HTTP Basic Authentication
HTTP protocol을 사용하는 가장 기본적인 인증 방법 입니다.
username과 password를 username:password 형태로 바꾼 후 Base64로 인코딩 후 매번 서버에 요청시 해당 값을 같이 전달하는 방식 입니다.
매우 간단합니다. 하지만 base64로 인코딩만 하기 때문에 보안에 취약하며, 매요청마다 credentials를 같이 전송해야 하는 단점이 있습니다.
보안에 취약한 단점을 해결하는 방법은 어떤 것이 있을까요?
HTTP Digest Authentication
HTTP Digest Authentication은 HTTP Basic Authentication에서 password에 암호화를 추가하였습니다.
HTTP Basic Authentication보다 보안성이 높기는 하지만, man-in-middle-attack는 여전히 취약하면, 매요청마다 credential를 전송해야하는 단점 또한 있습니다.
이러한 단점들을 해결할 수 있는 방법은 무엇일까요?
Session-based Auth
session-based auth(session cookie auth, cookie-based auth와 동일)은 유저의 상태를 서버에 저장하는 방법입니다. 때문에 매번 유저의 아이디와 패스워드가 요청마다 필요하지 않습니다. 대신에 로그인 이후 서버는 session ID를 브라우저에 전송해주며 브라우저는 이후의 요청에 sessionID를 이용하여 인증합니다.
서버에서 세션을 관리하기 떄문에 보안성이 높습니다. 하지만 Session-based Auth는 stateful하여 stateless architecutre인 REST 패러다임과 충돌합니다. stateful은 서버 부하의 원인이 됩니다. 또한, 서버의 규모가 켜져 MSA를 적용하였을 때 모든 서버가 SessionID를 공유해야 하는 문제점이 있습니다.
Stateful 방법은 보안성이 높기는 하나 성능에 오버헤드를 야기합니다. 그러면 어떤 방법이 이러한 문제점을 해결할 수 있을까요?
Token-Based Authentication
Token-Based Authentication은 sessionID대신 token을 사용합니다.
먼저, token-based authentication에서 가장 많이 사용하는 standard는 Json Web Token(JWT)의 구조에 대해서 알아보겠습니다.
JWT는 아래 3가지 요소로 구성 되어있습니다.
- Header: 토큰 타입과 해싱 알고리즘이 저장
- Payload: name/value 한쌍의 집합으로 정보가 저장되어 있습니다. 이 정보의 단위를 'claim'이라고 부릅니다.
- Signature: Header, Payload, secret key를 인코딩한 서명이 저장되어 있습니다.
JWT의 요소 중 Signature는 Header에 저장되어있는 해싱 알고리즘과 (보통) 서버가 갖고 있는 secret key(보통 private key)로 암호화되어 있습니다. 때문에 암호화된 토큰은 secret key를 갖고 있는 서버에서만 복호화 됩니다.
stateless하여 오버헤드를 없애기는 했으나, 여전히 XSS 또는 CSRF에 취약합니다. 만약 공격을 당하여도 해당 token을 지울 수 없기 때문에 만료기간을 저장해야 하는 단점을 가지고 있습니다.
참고자료
