Authentication(인증)과 Authorization(인가,권한 부여)에 대하여

인증/인가로 불리는 그것의 정체

Authentication과 Authorization은 Back-End(server) 작업시 빼 놓을 수 없는 부분이다. 
이 때,.Authentication은 인증, Authorization은 인가(또는 권한부여)로 보통 번역하며, 두 개를 묶어서 '인증/인가'로 부른다.

이러한 관행은 초보 프로그래머로 하여금 인증과 인가를 거의 유사한 개념으로 인식하게 만들고, 양자의 차이를 명확히 구분하지 못하게 만든다고 생각한다. 따라서 나는 인가를 '권한 부여'로 번역하는 스타일을 더 선호한다.

일반적으로 정상적인(?) 프로세스에서는 인증을 진행한 후에야 권한 부여가 진행된다는 점에서 인증과 권한 부여 사이의 시간적 선후관계는 존재한다고 볼 수 있다. 하지만, 인증과 권한 부여는 별개의 목적을 지닌 전혀 다른 프로세스이다. 극단적인 예로, 인증 없이도 권한 부여 프로세스를 진행할 수도 있고, 권한 부여 없이 인증만 진행할 수도 있다.

 

인증 (Authentication, AuthN)

개념

인증은 '식별 내지는 신원 확인'이 목적이다. 즉, Server로 하여금 현재 request를 보내는 자가 누구인지를 식별할 수 있도록 만든 프로세스라는 의미이다. 따라서, 일반적으로 인증 프로세스는 아래의 절차를 따른다.

1. User가 입력한 자격증명 정보(ID, Password)를 Server로 전송 및 인증 요청(req)
2. Server는 요청과 함께 전달 받은 자격증명 정보를 토대로 Server와 연결된 User 관련 DB를 참조하여 request를 보내는 자가 누구인지 식별

결과적으로 인증 프로세스를 사용자 측에서 본다면, '로그인' 부분을 뜻한다고 이해해도 무방하다.

인증 요소(Factor)의 분류

최근에 인증 프로세스와 관련해서 SFA, 2FA, MFA 등의 기술이 등장하고 있는데, 이는 인증 요소의 분류와 관련된 개념이다.

1. 지식 기반 요소 : 특정인이 알고 있는 정보 따위를 바탕으로 인증 (비밀번호 등)
2. 소유 기반 요소: 특정인이 소유하고 있는 물건을 바탕으로 인증 (OTP, 휴대폰 인증, 공인인증서 등)
3. 속성 기반 요소: 특정인의 고유 속성을 바탕으로 인증 (지문인식, 홍채인식 등)

위 요소의 나열 순서는 시간적 순서이다. 가장 원시적인 방법은 지식기반이었지만, 최근에는 소유기반을 넘어 속성기반으로의 인증이 점차 흔해지고 있다. 또한, 뒤에 등장한 방법일수록 보안성이 더 높다.

이 때, 단일 기반의 요소만을 통해 인증이 이루어지는 경우를 SFA(Single Factor Authentication),
두 가지 기반의 요소를 통해 인증이 이루어지는 경우를 2FA(Two Factor Authentication)라고 부르며,
두 가지 이상의 기반 요소를 통해 인증이 이루어지는 경우를 MFA(Multi Factor Authentication)라고 부른다.

최근에는 비밀번호 없는 인증 기술의 논의가 활발하다.

300x250

 

권한 부여 (Authorization, AuthZ)

개념

반면, 권한 부여(인가)는 말그대로 '권한 부여'가 목적이다. 이 과정에서 '인증' 프로세스에서의 식별 결과를 활용하기도 하지만, 이는 어디까지나 권한의 차등적 부여를 위해 존재하는 것일뿐, 인가 프로세스의 필수요건은 아니다. 어떻게 만드느냐에 따라서, Server가 현재 request를 보내는 사람이 누구인지 전혀 모르더라도 권한을 부여하도록 만들 수도 있다.

일반적으로 권한 부여 프로세스는 아래의 절차를 따른다.

1. User의 접근 권한 요청(req)
2. 요청과 함께 전달 받은 권한의 차등적 부여 관련 정보를 토대로 승인/거부

여기서 밑줄 친 '권한의 차등적 부여 관련 정보'와 관련해서 각종 Authorization 관련 기술들에 존재하는데, 대표적으로 Session에 특정 값을 넣어두고서 이를 체크하는 간단한 방식부터, JWT(JSON Web Token)이나 SAML(Security Assurance Markup Language), OAuth와 같은 기술들이 그것이다.

 

그렇다면 왜 대부분의 사람들이 '인증/인가' 로 묶어서 취급할까?

사실 이 의문은 실제로 인증과 권한 부여 프로세스를 개발해보면 저절로 풀리는 측면이 없잖아 있다.

현실적으로는 User의 인증 요청을 받으면 Server는 자격증명 정보를 통해 해당 User가 누구인지 식별하게 되고 그와 동시에 식별정보를 바탕으로 DB를 조회하여 권한 정보가 담긴 JWT나 API Key 따위를 응답해주게 된다. 그 이후 권한 부여 프로세스가 발생할 때마다 Server는 해당 Token 따위만 확인한 뒤, 별도의 DB조회없이 Server에서 바로 접근을 허가해주는 식.

이는 인증 요청을 받았을 때 정말로 인증 프로세스에 걸맞게 식별까지만 완료한다면, 추후 권한 요청이 있을 때마다 DB를 통해 권한 여부를 확인해야 하는 비효율성이 생기기 때문이다. 거의 모든 인증을 요구 하는 서비스에서는 당연히 인증 이후 권한 부여가 예정되어 있으므로 인증단계에서 바로 권한 부여에 관한 데이터를 한꺼번에 조회해오는 것. 식별이 끝나는 순간 바로 해당 유저의 권한에 맞는 신분증을 손에 쥐여 준다면, 권한 요청이 있을 때 Server는 별도의 DB 연결 없이 신분증만 확인하면 되기 때문에 훨씬 효율적이다.

위로 올라가서 권한 부여 파트의 절차 부분을 보면 '2. 요청과 함께 전달 받은 권한의 차등적 부여 관련 정보를 토대로~'라고 서술해뒀는데 이처럼 User가 접근 요청과 함께 뭔가를 보내줄 그 정보라는 것이 바로 JWT나 API Key 따위(신분증)인 셈.

따라서 인증 프로세스에서 요청에 따른 응답과정에 인가와 관련된 부분이 섞여 있다는 점에서 일반적으로 '인증/인가' 로 묶어서 취급하게 된다. 개발 단계에서는 두 로직이 맞닿아 있으므로...