토큰 기반 인증이란? 인증 토큰의 종류와 JWT의 이점

토큰 기반 인증이란? 인증 토큰의 종류와 JWT의 이점

토큰 기반 인증이란? 인증 토큰의 종류와 JWT의 이점

토큰 기반 인증이란 사용자가 자신의 아이덴티티를 확인하고 고유한 액세스 토큰을 받을 수 있는 프로토콜을 말합니다. 사용자는 토큰 유효 기간 동안 동일한 웹페이지나 앱, 혹은 그 밖에 해당 토큰으로 보호를 받는 리소스로 돌아갈 때마다 자격 증명을 다시 입력할 필요 없이 토큰이 발급된 웹사이트나 앱에 액세스할 수 있습니다.

인증 토큰은 도장이 찍힌 티켓과 같습니다. 토큰이 유효하다면 사용자는 계속해서 액세스할 수 있습니다. 사용자가 로그아웃하거나 앱을 종료하면 토큰도 무효화됩니다.

토큰 기반 인증은 비밀번호 기반 또는 서버 기반 인증 기법과는 다릅니다. 토큰이 두 번째 보안 계층을 제공하여 관리자가 각 작업과 트랜잭션을 정밀하게 제어할 수 있습니다.

하지만 토큰을 사용하려면 약간의 코딩 노하우가 필요합니다. 개발자들은 대체로 이러한 기법을 빠르게 습득하지만 학습 곡선도 존재합니다.

그럼 이제 고객과 고객 기업별로 어떤 토큰이 적합한지 자세히 알아보겠습니다. 

인증 토큰의 역사

인증과 인가 (권한 부여)는 서로 다른 개념이지만 연관성이 있습니다. 인증 토큰을 사용하기 전에는 비밀번호와 서버가 사용되었습니다. 기존 방식을 사용해 적합한 사람이 필요할 때 원하는 정보에 액세스했는지 확인해야 했지만 항상 효과적이지는 못했습니다.

비밀번호를 예로 들면, 일반적으로 다음과 같은 과정이 작용합니다.

  • 사용자 생성. 문자, 숫자, 기호를 조합하여 비밀번호를 생성합니다.
  • 기억. 고유한 비밀번호 조합을 항상 기억해야 합니다.
  • 반복. 액세스가 필요할 때마다 비밀번호를 입력해야 합니다.

또한 유저들은 비밀번호를 일일이 다 기억하지 못하며, 다음과 같은 요령에 의지하는 경우가 많습니다.

  • 비밀번호 기록. 비밀번호가 빼곡히 적힌 종이를 분실할 경우 보안 악몽이 시작됩니다.
  • 비밀번호 재사용. 사람들은 동일한 비밀번호를 여러 계정에서 사용하는 경향이 있습니다. 따라서 한 개의 비밀번호가 분실될 경우 대부분의 계정이 취약해질 수 있습니다.
  • 부분적인 비밀번호 변경. 사람들은 비밀번호를 업데이트해야 할 때 문자나 숫자를 하나만 변경합니다.

비밀번호 역시 서버 인증이 필요합니다. 사람들이 로그인할 때마다 컴퓨터가 트랜잭션 레코드를 생성하며, 결과적으로 메모리 부하가 증가합니다.

하지만 토큰 인증은 다릅니다.

토큰 인증 방식에서는 보조 서비스를 통해 서버 요청을 확인합니다. 확인이 완료되면 서버가 토큰을 발급하여 요청에 응답합니다.

사용자는 여전히  적어도 한 개의 비밀번호 를 기억해야 하지만 토큰이 액세스 계층을 하나 더 제공하기 때문에 도용하거나 침투하기가 훨씬 더 어렵습니다. 또한 세션 레코드가 서버에서 공간을 전혀 차지하지 않습니다. 

세 가지 유형의 인증 토큰

모든 인증 토큰이 액세스를 허용하지만 각 유형마다 약간씩 차이가 있습니다.

일반적으로 다음과 같은 세 가지 유형의 인증 토큰이 사용됩니다.

  • 연결형: 키, 디스크, 드라이브 및 기타 물리적 장치가 시스템에 연결되어 액세스를 허용합니다. USB 디바이스나 스마트카드를 사용해 시스템에 로그인한 경험이 있다면 연결식 토큰을 사용한 셈입니다.
  • 비접촉형: 디바이스가 서버와 통신하려면 거리가 충분히 가까워야 하지만 연결할 필요는 없습니다. Microsoft의 "매직 링"이라고 하는 토큰이 여기에 해당합니다.
  • 분리형: 디바이스가 다른 디바이스와 접촉하지 않고도 먼 거리에서 서버와 통신할 수 있습니다. 예를 들어 이중 요소 인증 프로세스에 휴대전화를 사용한 경험이 있다면 이러한 유형의 토큰을 사용한 셈입니다.

위의 세 가지 시나리오 모두 사용자가 무언가를 해야만 프로세스가 시작됩니다. 비밀번호를 입력해야 할 수도 있고, 혹은 질문에 답변해야 할 수도 있습니다. 하지만 예비 단계를 완벽하게 마쳤다고 해도 액세스 토큰이 없으면 액세스하지 못합니다. 

4가지 단계의 간단한 토큰 인증 절차

토큰 기반 인증 시스템을 사용하면 방문자가 자격 증명을 한 번만 확인합니다. 자격 증명이 확인되면 토큰이 할당되어 정해진 시간 동안 액세스가 가능합니다.

프로세스는 다음과 같습니다.

  • 요청: 사용자가 서버 또는 보호되는 리소스에 대한 액세스를 요청합니다. 이때 비밀번호를 이용한 로그인이나 그 밖에 지정된 프로세스가 개입될 수 있습니다.
  • 확인: 서버가 해당 사용자의 액세스 여부를 확인합니다. 이때는 사용자 이름에 대한 비밀번호 확인 또는 그 밖에 지정된 프로세스가 개입됩니다.
  • 토큰: 서버가 링, 키, 휴대전화와 등의 인증 디바이스와 통신합니다. 확인을 마치면 서버가 토큰을 발급하여 사용자에게 전달합니다.
  • 저장: 작업이 지속되는 동안 토큰이 사용자의 브라우저에 저장됩니다.

사용자가 서버에서 다른 곳에 방문하려고 하면 토큰이 서버와 다시 통신합니다. 토큰에 따라 액세스가 허용되기도 하고 거부되기도 합니다.

관리자가 토큰에 대한 사용 제한을 설정하기도 합니다. 예를들어, 사용자가 로그아웃하 지정된 시간이 지나면 토큰이 자동으로 파기되도록 설정할 수 있습니다.

Token Based Authentication

JSON Web Token(JWT): 특별한 인증 토큰

오늘날 휴대전화(앱)와 웹 앱을 통해 시스템에 액세스하는 사용자들이 많아지면서 개발자에게 이러한 플랫폼에 적합한 안전한 인증 방법이 필요해졌습니다.

개발자들은 애플리케이션에 토큰 인증 방식을 도입할 때 이러한 문제를 해결하기 위해 JSON Seb Token(JWT)으로 눈을 돌리고 있습니다.

JSON Web Token(JWT)은 개방형 표준입니다. 완성된 코딩 결과물은 발신자와 수신자 사이에서 안전한 통신을 지원합니다. 데이터는 디지털 서명을 통해 확인하며, HTTP를 통해 전송되는 경우에는 데이터를 암호화하여 안전하게 보호합니다.
 

JWT에는 세 가지 중요한 구성요소가 있습니다.

  1. 헤더: 토큰 유형을 비롯해 관련된 서명 알고리즘을 정의합니다.
  2. 페이로드: 토큰 발급자, 토큰 유효기간 등을 정의합니다.
  3. 서명: 보안 서명을 통해 메시지가 전송 과정에서 바뀌지 않은 것을 확인합니다.

코딩은 위의 세 가지 요소로 이어집니다.

JSON 코드를 보고 긴장할 필요는 없습니다. 이러한 유형의 표기는 엔티티가 데이터를 앞뒤로 전달할 때 흔하게 사용되는 것으로, 자습서도 많이 있습니다. JSON 토큰을 사용하고 싶지만 해당 언어를 시도해 본 경험이 없다면 이러한 리소스가 도움이 될 수 있습니다.

JWT의 장점과 단점

JWT에는 다음과 같은 다양한 장점이 있습니다.

  • 크기: JSON 코드 언어로 생성된 토큰은 용량이 작기 때문에 두 엔티티 사이에서 매우 빠르게 전달됩니다.
  • 용이성: 거의 모든 곳에서 토큰이 생성될 수 있으며, 서버에서 토큰을 확인할 필요가 없습니다.
  • 제어: 액세스 가능한 데이터, 권한 지속 시간, 로그인 시 가능한 작업을 지정할 수 있습니다.

반면 잠재적 단점도 존재합니다.

  • 단일 키: JWT는 단일 키를 이용합니다. 따라서 키가 유출되면 시스템 전체가 위험에 노출됩니다.
  • 복잡성: 이 토큰은 이해하기가 쉽지 않습니다. 개발자가 암호 서명 알고리즘에 정통하지 않다면 자신도 모르게 시스템을 위험에 빠뜨릴 수 있습니다.
  • 제한: 메시지를 모든 클라이언트에게 푸시할 수 없고, 서버 측 클라이언트도 관리할 수 없습니다.

인증 토큰을 시도해야 하는 이유

누구나 현재 전략을 평가하고 아무런 문제가 없다고 생각할 수 있습니다. 그런데도 인증 토큰을 시스템에 추가해야 하는 이유는 무엇일까요? 결단을 내리는 개발자들이 실감할 수 있는 이점이 있기 때문입니다.

인증 토큰은 다음과 같은 시스템 관리자에게 유용합니다.

  • 임시 액세스를 자주 허용하는 관리자. 날짜, 시간 또는 특별 이벤트에 따라 사용자 수의 변동 폭이 크면 액세스를 반복해서 허용 또는 취소하느라 쉽게 지칠 수 있습니다. 이때는 토큰이 유용합니다.

    예를 들어 대학 도서관 사이트의 관리자라면 아마 토큰 접근법의 진가를 알아볼 것입니다.

  • 액세스 세분화가 필요한 관리자. 서버가 사용자 속성이 아닌 특정 문서 속성에 따라 액세스를 허용합니다. 하지만 비밀번호로는 정밀한 세분화가 어렵습니다.

    예를 들어 온라인 저널을 운영한다고 가정했을 때, 모든 독자가 여러 문서가 아닌 한 문서에서 저널을 읽고 댓글을 달 수 있도록 만들려고 합니다. 이때 토큰을 사용하면 가능합니다.

  • 주요 해킹 표적인 관리자. 유출될 경우 기업에게 심각한 피해를 입힐 정도로 중요한 문서가 서버에 저장되어 있습니다. 비밀번호로만으로는 충분히 보호하기 어렵습니다. 이때는 하드웨어가 큰 도움이 될 수 있습니다.

인증 토큰의 사용 사례는 이 외에도 많습니다. 하지만 위의 사용 사례도 창의력을 발휘하는 데 유용하며, 이점을 고려할수록 인증 토큰을 사용할 가능성도 더 커집니다. 

인증 토큰 모범 사례 따라하기

인증 토큰은 보안 프로토콜을 강화하여 서버를 안전하게 보호하는 데 목적이 있습니다. 하지만 안전을 염두에 두고 프로세스를 구축하지 않는다면 인증 토큰도 효과를 발휘하지 못합니다.

인증 토큰은 다음과 같아야 합니다.

  • 비공개. 사용자는 여러 부서 사이에서 토큰 인증 디바이스를 공유하거나 함께 사용할 수 없습니다. 비밀번호를 공유하지 않듯이 보안 시스템에서 어떤 것도 공유해서는 안 됩니다.
  • 보안. 토큰과 서버 간 통신은 HTTPS 연결을 통해 안전하게 보호되어야 합니다. 암호화는 토큰을 안전하게 보호하기 위한 필수 요소입니다.
  • 테스트. 토큰 테스트를 주기적으로 시행하여 시스템이 안전하게 정상적으로 작동하는지 확인해야 합니다. 또한 문제가 발견되면 신속하게 해결해야 합니다.
  • 적합성. 각 사용 사례에 적합한 유형의 토큰을 선택해야 합니다. 예를 들어 JWT의 경우 세션 토큰에 적합하지 않은데, 이는 비용이 만만치 않을 뿐만 아니라 가로채기로 인한 보안 위협을 배제할 수 없기 때문입니다. 따라서 작업에 적합한 툴인지 항상 확인해야 합니다.

인증 토큰을 쉽게 결정해서는 안 됩니다. 직접 알아보거나 동료들에게 물어봐서 회사에게 가장 필요한 일을 하고 있는지 생각해 보는 것이 좋습니다. 

Okta가 도와드리겠습니다

Okta는 집이나 회사 시스템에 대한 액세스를 안전하게 보호할 방법을 끊임없이 모색하고 있지만 권한을 가진 사용자만 디지털 리소스에 액세스할 수 있도록 제한하려면 토큰 기반 인증과 같은 메커니즘을 구현하는 것도 못지 않게 중요합니다.

Okta가 어떻게 세상을 안전하게 보호하고 있는지 알아보세요.

참고 자료

The World's First Computer Password? It Was Useless Too. (2012년 1월). Wired.

Microsoft Says This Magic Ring Could Make Passwords Obsolete. (2020년 6월). Small Business Trends.

JSON Web Token. (2015년 5월). Internet Engineering Task Force.

Working With JSON. Mozilla.

Security Token. Citi.

Security Token Definition. (2020년 6월). Investopedia.

Two-Factor Authentication. (2020년 2월). Explain That Stuff.

When Are Tokens Securities? Some Questions from the Perplexed. (2018년 12월). Harvard Law School Forum on Corporate Governance

자세한 내용이 궁금하신가요?

Okta Adaptive Multi-factor Authentication은 비밀번호가 필요 없는 인증 환경으로 나아가는 첫 단계입니다.