토큰을 사용하는 주요한 이유누가 Token-Based Authentication을 이용해?Server Based Authentication ( 전통적인 방법)Server-Based Authentication의 문제점 ⇒ Scalability가 main 이슈토큰 기반 인증?작동방식토큰의 유용성Software based 토큰의 단점Authentication Token의 주요 종류토큰 기반 인증은 안전한가
참고 링크
토큰을 사용하는 주요한 이유
- API 를 사용하는 대부분의 웹 회사들은 token이 다수 유저의 인증을 다루기 위해서는 가장 좋은 방법이다
- Stateless, scalable server
- 모바일 앱개발도 가능
- 인증을 다른 어플리케이션으로 넘김(Pass authentication to other applications)
- 추가 보안(Extra security)
누가 Token-Based Authentication을 이용해?
- 페이스북
- 트위터
- 구글+
- Github
Server Based Authentication ( 전통적인 방법)
- HTTP 프로토콜이 stateless 이기에, 첫번째 request와 그 다음의 request 사이에 인증을 유지할 수 있는 방법이 없음 (매 request 마다 username과 password로 인증을 해야 되는 것임) ⇒ application이 우리가 누구인지 기억하게 하기 위해, 서버에 유저 로그인 정보를 저장 (memory or disk)
- web, application, mobile application이 등장함에 따라 이 방식의 인증은 scalability에서 단점을 보임
Server-Based Authentication의 문제점 ⇒ Scalability가 main 이슈
- Session : 유저가 인증될 때마다 서버는 기록을 어딘가에 남겨야 하고, 이게 일반적으로 메모리에 됨 ⇒ 많은 유저가 인증을 할 때 서버의 오버헤드가 증가하게 됨
- Scalability : 세션이 메모리에 저장되기 때문에 scalability에 문제를 가져오게 됨. cloud provider가 application load를 분산하기 위해 서버를 복제하게 된다면(Scale-out) 한 서버의 세션 메모리에 저장된 중요한 정보는 다른 서버에서는 접근이 불가하여 모든 서버에서 공통적으로 다 같이 쓸수가 없음 ⇒ Scalability 를 제한함
- CORS : application을 확장하기 위해 여러 모바일 장치에서 데이터를 사용하게 한다면, CORS 문제가 생기게 됨. AJAX를 이용하여 다른 도메인에서 resource에 접근하면 (mobile to API server), forbidden request 문제에 맞닥뜨리게 됨
- CSRF : 은행 사이트에서 이미 인증이 되었기 때문에 유저는 CSRF 공격에 노출되게 됨. 또는 다른 사이트에 방문할 때도 이것을 이용할 수 있게 됨
토큰 기반 인증?
- 토큰 기반 인증은 알고있는 유저(로그인된 유저)에 대해 인증 과정을 단순화 시켜줌
- 처음에 username과 password를 보내고 난 뒤는 request에 token이 자동으로 포함되기에 유저가 편함
- 토큰 기반 인증은 stateless 함. 사용자에 대한 어떠한 정보도 서버나 세션에 저장하지 않음 ⇒ 세션 정보를 가지고 있지 않다는 말은 application이 유저 로그인에 대한 걱정 없이 Scale-out 할 수 있다는 것을 의미함
- 토큰은 user credential과 data 를 보안상 안전한 방법으로 보관함
작동방식
- 구현 방식은 다를 수 있지만 핵심적인 작동 방식은 아래와 같음
- Initial Request — 유저 접근 요청(Username, Password)
- Verification — 어플리케이션에서 credential을 validate(credential database 조회를 통해서)
- Tokens — client에게 signed token을 반환(db 에 token을 보관할 수도 있음)
- hardware token의 경우 물리적으로 token을 provisioning 하는 것 까지를 포함함
- software token은 client의 background와 server 사이에서 일어나게 됨
- Persistency — client가 토큰을 저장하고 그 토큰을 매 요청마다 같이 보냄
- 토큰이 유저에 의해 저장됨(물리적으로 혹은 브라우저, 모바일 폰에서)
- 서버가 token을 verify하고 데이터 응답을 내려줌
- 모든 요청이 token을 필요로 하게 되고 HTTP 헤더를 통해 같이 보내짐
Access-Control-Allow-Origin : *를 서버에서 세팅해주어야 하고 이렇게 함에 따라 request가 credential을 제공하는 것을 막게 됨(HTTP authentication, client-side SSL certificates, cookies)
토큰의 유용성
stateless & Scalable
- 토큰은 클라이언트 사이드에 저장되기 때문에 로드 밸런서가 유저를 어떠한 서버에 넘겨주더라도 상관이 없다 ⇒ Scale out이 쉬움!!
- 만약 세션 정보를 저장하고 있다면 인증된 유저는 계속해서 똑같은 서버로 연결시켜주어야 함(session affinitiy)
- 서버에서 쉽게 필요한 만큼 많이 토큰을 만들고 검증도 가능함
Security
- 쿠키가 아닌 토큰은 매 요청마다 보내지는데, 쿠키가 전송되는 것은 아니기 때문에 CSRF 공격을 막는데 도움을 줄 수 있다.
- 만약 특정 구현이 client-side에서 토큰을 쿠키안에 저장한다고 하더라도 쿠키는 인증 방식이 아닌 단순한 저장 메커니즘임. 토큰 사용하면 관리해야 할 session-based information이 없다(세션을 이용하면 쿠키는 같이 쓰게 됨. 쿠키에 세션 정보를(세션ID) 담아서 구현하기 때문에 결국 쿠키와 세션은 같이 가는 것인 것 같음)
- 토큰은 특정 시간 이후에 만료되기 때문에, 사용자는 다시 로그인 해야 함
- 또한 token revocation(토큰 폐지) 개념이 있어서 특정 토큰을 invalidate 할 수도 있고 같은 Authorization grant의 토큰 그룹에 대해서도 무효화 시킬 수 있음
Extensibility (Friend of a friend and Permissions)
- 토큰은 다른 어플리케이션과 permission을 공유하는 어플리케이션을 만들 수 있게 도와줌
- 예를 들어, 임의의 소셜 계정을 Facebook이나 Twitter와 같은 major한 소셜에 연결 할 수 있음
- 어떤 서비스(let’s say Buffer)를 통해 Twitter에 로그인 했다면, Buffer에게 Twitter stream에 post를 할 수 있도록 허락해 줄 수도 있는 것임
- 토큰을 이용하면 third-party application에 선택적인 권한(selective permission)을 줄 수 있음
- 우리의 유저가 그 유저의 데이터를 다른 application에 제공할 수 있도록 special permission token을 배부하는 식으로 API를 구성할 수 있는 것
Multiple Platforms and Domains
- 어플리케이션, 서비스가 확장하게 되면 다양한 종류의 기기, 어플리케이션에 접근을 제공해야 하게 됨
- 우리의 API 가 그냥 데이터를 제공할 수 있게 구성한다면(
Access-Control-Allow-Origin : *) CDN에서 asset을 제공하도록 구성을 할 수도 있는 것 ⇒ CORS 이슈를 제거해줌 - 우리의 데이터, 리소스는 유효한 토큰을 가지고 있는 어떠한 도메인의 요청에도 이용가능하게 되는 것임
Standards-Based
- 토큰을 만들 때, 몇 가지 옵션이 있음
- hardware-based tokens
- one-time passwords (usually granted via mobile phones)
- software-based tokens ⇒ standard 로 사용하는 것은 JWT(JSON Web Tokens)
- OAuth
Flexibility
- Software-based token은 여러 대의 서버에서 사용될 수 있고 다수의 웹사이트와 어플리케이션에 동시적으로 인증을 제공할 수 있음
- Software-based token은 일반적으로 Single sign on( SSO)를 구현하기 위해 사용됨
Software based 토큰의 단점
Compromised(위태롭게 되어 공격 받아 기능이 제대로 발휘되지 못하는) Secret Key
- JWT standard의 가장 큰 단점은 하나의 키에 의존한다는 점임
- 만약 private key가 개발자에 의해서 잘 다뤄지지 않는 경우, 공격자에 의해 탈취된다면 민감한 정보들을 위험에 노출시키게 되는 것임
Data Overhead
- JWT 의 크기는 일반적인 세션 토큰에 비해서는 많이 큼
- 클라이언트에 관한 저장된 정보로 인해 점점 더 커지게 됨
- 토큰에 더 많은 데이터를 추가하게 되는 것은 유저 세션을 만드는 시간에 영향을 줄 수 있고, 결론적으로 페이지 로드 시간을 증가시킬 수 있음
장기간 인증에는 맞지 않음
유저가 로그인 되어 있는 상태를 오랫동안 유지하는 것은 이상적이지 않긴 함
그러나 이러한 토큰을 이용하면 자주 재검증을 해야 해서 사용자를 힘들게 할 수 있음 ⇒ refresh token을 활용 & 그것들을 저장해서 사용하는 것도 좋은 방법. Refresh token을 이용하면 유저가 다시 재인증할 필요 없이 인증 상태를 더 길게 가져갈 수 있음
Authentication Token의 주요 종류
Hardware Tokens (USB Tokens)
- 물리적 기기를 주로 말함
- 하드웨어 토큰의 목적은 보안의 계층을 더 두기 위함임 (two-factor, multi-factor authentication). 2FA, MFA
- 하드웨어 토큰은 사용자 경험(UX)과 사용자 개인화(customizability)를 위해 디자인 되었어서, 다양한 형태로 발급되는데 가장 일반적인 형태는 key fobs, USB, wireless token임
- 3가지 카테고리로 나누어짐
- Contactless : 시스템에 접근하기 위해 무선 연결을 이용함. 연결과 관련된 credential을 이용하여 승인 거부를 판단함
- Disconnected : 시스템에 접근하기 위해 물리적으로 삽입되거나 할 필요가 없음. device에 일회용 접근 코드를 발급해주는 것을 셋팅함으로써 동작하게 됨(2FA, MFA의 일부분으로서 제공). 보통 모바일 디바이스
- Connected : 접근을 허용케 하기 위해 시스템에 물리적으로 연결되어야 함. USB token 이나 key fob이 될 수 있음
JSON Web Tokens (JWT)
- open standard (RFC 7519)
- defineds a simple, self-contained method for transmitting information btw parties securely
- JWT standard는 Javascript Object Notation(JSON) 객체를 사용해서 여러 파티 사이에서 토큰을 전하게 됨
- 사이즈가 작아서 URL, Post 파라미터, HTTP header 등으로 빠르게 전달이 가능함
- JWT 는 entity에 필요한 모든 정보를 포함하고 있어서, db에 여러번의 쿼리가 날라가는 것을 방지해줌
One-Time Password (OTP) Tokens
- 일회성 비밀번호를 만들어내는 안전한 하드웨어 기기나 소프트웨어 프로그램을 말함
- 가장 일반적으로 personal identification numbers (PIN), 숫자 코드(4-12 digits 사이)가 있음
- 스마트폰이 일회성 비밀번호를 만들거나 받는데에 일반적으로 많이 사용되게 됨. 먼저 사용자가 해당 휴대폰의 소유권을 증명하고 나면, OTP 비밀번호를 만들어주는 authenticator app을 이용할 수 있게 되는 형태로.
- 또는, 기기에 SMS으로 OTP가 보내지기도 함
API Tokens
- 한마디로 말하면 API 토큰은
특정 서비스에 접근을 요청하는어플리케이션의 고유한 식별자로 사용이 됨
서비스는어플리케이션을 위한 API 토큰을 생성해서해당 서비스에 요청을 보내게 해줌- 그럼, API 토큰은 저장된 것과 비교하여 인증을 하고, 접근을 허용하게 됨
- API 토큰은 username과 password를 HTTP로 보내는 안전하지 않은 방식을 대체하기 위해 유명세를 얻고 있음 ⇒ OAuth2 (access tokens)이 가장 일반적인 방식
토큰 기반 인증은 안전한가
- phishing, brute force and dictionary attacks과 같은 credential을 대상으로 한 사이버 공격이 계속해서 증가하고 있기에 인증을 비밀번호 하나에만 의존할 수는 없는 상황이 되었음
- 추가적인 인증 기술과 결합됨에 따라 토큰 기반 인증은 해커가 비밀번호를 훔쳐서 이용하는데 있어 더 복잡한 방어막을 세울 수 있게 됨
- 토큰은 해당 토큰을 만들어낸 고유 기기(smartphone, key fob)에서만 가져갈 수 있다는 점으로 인해 고효율의 인증방식이 되어가고 있음
- 그러나, 잔존하는 리스크는 있다
- 디바이스에서 토큰이 텍스트로 전송되게 되면 중간에 가로채질 수 있다는점
- 디바이스가 분실, 훔쳐지면 악의적인 의도로 디바이스에 저장된 토큰에 접근이 가능하게 됨
- 결론, 하나의 인증 방식에만 의존하지 말라는 것을 명심하기. 토큰 기반 인증은 2FA, MFA 의 하나의 컴포넌트로써 고려가 되어야 하는 것임