인증과 인가의 차이, 자세히 알아보자

들어가며

친구가 인증, 인가의 차이에 대해 물어보았다. 그런데 나도 곰곰히 생각을 해보니 명확하게 둘의 차이에 대해 말하기가 쉽지 않았다. 내가 잘 모르니 이해시키는 것은 어불성설이다. JWT 토큰이 회원 가입, 로그인을 하면 서버에서 무언가 데이터로 토큰을 발급을 해서 ~~~ … 이렇게 인증과 인가의 전체 프로세스적인 부분에서는 다소 익숙하지만 정확한 정의와 차이점에 대해서는 지식이 부족한 것 같다.

그래서, 이번 포스팅에서는 인증과 인가의 정의, 개념에 대해 정확히 이해해보고 다음 포스팅에서는 Nest.js 를 통해 어떻게 Jwt Strategy 를 통해 인증과 인가를 구현하는지 풀어보고자한다!

인증과 인가의 차이점이 모호해요 ..

사실, 인증과 인가는 완전히 다른 개념이다. 둘 다 보안과 관련되었다는 점, JWT 토큰 기반인 경우 해당 토큰을 사용한다는 점에서는 동일하지만, 인증은 장치 혹은 사용자를 식별하는 행위이고 인가는 장치 및 사용자 엑세스 권한을 허용/거부하는 행위이다.

인증(Authentication)이란?

네이버 메일을 사용하고 싶어요!

인증은 어떤 사실 또는 어떤 문서가 진짜인지 증명하는 과정을 가리키는 용어입니다.
일반적으로 컴퓨터 과학 분야에서는 사용자의 신원을 증명하는 것과 관련이 있습니다.
사용자는 사용자와 시스템간에 공유되는 합의된 정보를 제공하여 자신의 신원을 증명합니다.

Auth0 의 설명을 해석해보면 “인증은 사용자가 사용자와 시스템간에 공유되는 합의된 정보를 시스템에게 전달하여 자신의 신원을 증명하는 과정”을 말한다.

오늘 아침 네이버 메일로 전달받은 문서를 확인하고 싶다고 생각해보자. 네이버 메일 서비스를 통해 내 메일을 확인할려면 위에 나온 이미지처럼 내가 회원가입에 사용한 아이디와 비밀번호를 통해 네이버 서비스에게 지금 접속하는 것이 내가 맞다는 것을 알려야한다.

여기서, 메일을 보고싶은 나는 사용자이고 네이버 메일 서비스는 시스템이다. 나는 네이버 메일 서비스에게 내 신원을 증명하기 위해 아이디와 비밀번호를 입력하고 인증 요청을 보낸다. 아이디와 비밀번호는 나와 네이버 메일 시스템간에 공유하는 합의된 정보이다.

내가 올바르게 아이디와 비밀번호를 입력했다면 네이버 시스템은 나의 신원을 인증하고 메일을 보기 위한 절차를 시작할 것이고 잘못 입력했다면 신원을 증명 할 수 없다는 것을 알려줄 것이다.

아이디와 비밀번호, 이것은 인증 요소

방금의 예시 상황에서 나와 시스템은 아이디와 비밀번호라는 합의된 정보를 공유하고 있음을 알 수 있다. 이런 합의된 정보를 “인증 요소” 라고 하는데 이러한 인증 요소는 크게 3가지 유형으로 분류 될 수 있다.

즉, 우리가 일반적으로 웹 서비스에서 아이디와 비밀번호를 통해 로그인 하는 행위는 “사용자가 아는 것” 이라는 인증 요소를 시스템에게 전달해 신원을 증명하는 행위이다.

회원가입도 프로세스의 흐름에 따라 다르겠지만, 가입시에 위의 3가지에 해당하는 방식으로 인증 요소를 입력하도록 하고 그것에 대해 증명하도록 한다면 이것은 인증의 절차이다.

예시를 들자면, 요즘 웹 서비스들은 “카카오톡으로 시작하기” 등의 방식으로 회원가입 없이 서비스를 이용 할 수 있도록 하는 경우가 있는데 이것은 “외재적인 인증 요소”를 사용해 나의 신원을 증명한 것과 동일하다.

내가 헷갈렸던 부분은 로그인, 회원가입 → 토큰 발급 → API 사용 가능 등의 프로세스로 구현되는 경우만을 보아와서 로그인과 회원가입 자체가 인증 과정이라고 생각을 하려하다보니, “로그인 회원가입하면 토큰을 주는데 이건 뭘까?? 인증과 인가가 합쳐진건가??” 햇던 부분이다. 실제로는 사용자가 인증 요소를 시스템과 공유하고 신원을 증명하는 것에 증명의 핵심이 있다는 것을 알게 되었다.

인가(Authorization)란?

인증과 달리 권한 부여는 엔터티(사용자 또는 장치)가 액세스할 수 있는 리소스 또는 수행할 수 있는 작업,
즉 액세스 권한을 확인하는 프로세스를 의미합니다.

위의 정의가 조금 모호할 수 있다. 예를 들면 이런 상황인데, 내가 우리 회사 건물의 101A 사무실로 들어가기 위해서는 카드키가 필요하다. 해당 카드키에는 내 사진과 이름등의 정보가 포함되어 있다. 보안 시스템은 해당 카드키를 통해 나의 신원을 확인함과 동시에 내가 사무실에 들어 갈 수 있는 사람임을 확인하고 들여보내준다.

이처럼, 일반적으로 인증과 인가의 과정은 특정 시나리오에서 상호 교환 가능하다. 어디까지가 인증이고 인가인지 나누는 것이 모호할 수 가 있다는 의미이다.

이전에 설명한 인증을 바탕으로 인가의 차이를 설명하면, 인증 → 인가로 이어질 수 있지만 인가 → 인증으로는 이어질 수 없다는 점이다.

예시를 다시 생각해보자. 카드키에는 내 정보가 포함되어 있으므로 사내 정보망에 등록된 내 정보를 토대로 내가 101A 사무실에 들어 갈 수 있다고 알 수 있을 것이다. 반대로, 내가 101A 사무실에 들어갈 수 있는 권한이 있다고 해서 항상 나임을 특정 할 수는 없다. 정리하면,

• 인증은 권한 부여 결정의 요소로 사용될 수 있다.
• 권한 부여는 인증을 하기에는 유용하지 않을 수 있다.
  
  

IAM 과 인가, 인가는 엑세스 정책과 매우 매우 밀접한 관계가 있어요!

위의 예시에서 카드키를 통해 101A 사무실에 출입 가능한 권한을 얻는 것은 컴퓨터 시스템에서 IAM(Identity and management)이라는 IT 규율의 일부로 표현 할 수 있다. 인가를 통한 권한 부여는 엑세스 정책과 밀접한 관계가 있다. 권한 부여 정책을 통해 엑세스 정책을 구현 할 수 있기 때문인데, 몇가지 권한 부여 정책을 소개해본다.

• ABAC (Attribute-Based Access Control)

  컴퓨터 시스템이 사용자에게 작업을 실행할 권한을 줄 기준을 사용자와 관련된 특성을 통해 판단한다. 예를 들어 물건 판매 시스템이 있을때 주류 등의 성인만 구매 할 수 있는 경우 사용자의 나이 라는 특성을 기준으로 물건 리스트를 조회하는 작업에 대한 권한을 부여할 것이다.

  • 온라인 물건 판매자는 리소스 소유자
  • 주류는 자원
  • 인증 과정에서 사용자의 신원을 증명하며 나이에 대한 증명도 처리된다.

• RBAC (Role-Based Access Control)

  사용자의 직접적인 정보가 아닌 사용자의 역할을 기반으로 엑세스를 제어한다. 역할은 단순히 권한의 모음이다. AWS IAM 을 통해 배포 자동화 시스템을 만드는 것을 생각해보자. Code Deploy 를 통해 배포 요청이 들어오면 S3 로 부터 압축 파일을 가져와 새로운 Ec2 인스턴스를 생성해야한다.

  이 경우 권한은 s3 로 부터 압축 파일을 가져올 권한, 새로운 ec2 인스턴스를 생성할 권한이 필요하다. 역할이란 이러한 권한을 묶은 “배포자 권한” 정도가 되지 않을까 싶다.

  • 사용자와 권한을 하나씩 처리하지 않고 범주의 개념으로 처리 가능 → 권한 관리가 용이

마치며

다음 포스팅에서는 JWT 토큰에 대해 자세히 알아보고자 한다! 토큰에 대한 정확한 개념과 더불어 인증/인가에서 토큰이 언제 어떻게 생성되고 어떻게 활용되는지에 대해 풀어보고자 한다.

이번에 이것 저것 공부를 하며 무엇이든 개념이 중요하다는 것을 다시 한번 깨우치게 되는 것 같다. 개인적으로는 어설프게 아는 것도 아는 것이다 라고 생각하는 편이기는 하지만, 개념을 정확히 알게되면 날개를 단 것 처럼 다양한 활용과 구체적인 구현이 가능해진다.

참고 자료

https://auth0.com/intro-to-iam/what-is-authorization

https://velog.io/@aaronddy/인증Authentication과-인가Authorization

https://docs.nestjs.com/guards