분야별 Token의 사전 정의
프로그래밍 언어에서의 토큰
문법적으로 더 이상 나눌 수 없는 기본적인 언어 요소를 말하는데, 예를 들어 하나의 키워드나 연산자 또는 구두점 등이 토큰이 될 수 있다.
네트워크에서 말하는 토큰
토큰링 네트워크를 따라 돌아다니는 일련의 특별한 비트열이다. 컴퓨터들은 네트웍을 따라 순환하는 토큰을 자신이 잡았을 때만 네트워크에 메시지를 보낼 수 있다. 각 네트워크에는 오직 단 한 개의 토큰만이 존재함으로써, 두 개 이상의 컴퓨터가 동시에 메시지를 전송할 가능성을 사전에 차단한다.
보안 시스템에서의 토큰
크레딧 카드 크기의 작은 장치를 말하는데, 계속해서 변화하는 ID 코드를 표시해준다. 사용자가 처음에 암호를 입력하면, 카드는 네트워크에 접속할 수 있는 ID를 그때그때 표시해준다. 보통, 매 5분마다 ID가 변경된다.
협력하여 일하는 행위자들 간에 공유자원 접근에 대한 동기화를 보장하기 위해 전달되는 추상적인 개념을 말한다. 이러한 토큰은 절대로 복사될 수도 손상될 수도 없으며, 토큰을 가진 사람이면 누구라도 특정 자원의 배타적 접근이 허용되며, 그것을 통제할 수 있는 권한을 가지게 된다. 예를 들어, 여러 명의 프로그래머가 하나의 프로그램을 협력하여 개발한다고 할 때, 어떤 순간에는 토큰을 가지고 있는 오직 단 한 명의 프로그래머만이 그 프로그램을 수정할 수 있으며, 다른 프로그래머들은 볼 수만 있다. 누군가가 그 프로그램을 수정하길 원하면, 먼저 토큰을 얻어야만 한다. 이렇게 하면, 여러 명의 프로그래머가 동시에 서로 다른 수정을 함으로써 야기될 수 있는 문제를 사전에 봉쇄할 수 있다.
토큰의 가장 큰 특징
Stateless 방식
1. 상태 유지를 하지 않는다는 것
2. 유저의 인증 정보를 서버나 세션에 담아두지 않음.
3. 세션이 존재하지 않으니, 유저들이 로그인되어있는지 안되어있는지 신경도 쓰지 않으면서 서버를 손쉽게 확장 가능.
반대로는 Stateful 방식이 있다. 특징으로는
서버는 클라이언트에게서 요청을 받을 때마다, 클라이언트의 상태를 계속해서 유지하고,
이 정보를 서비스 제공에 이용한다.
* 기존 세션을 이용하던 방식과 token을 이용하던 방식 비교
1. 서버 기반
문제점:
1. 세션
유저가 인증을 할 때, 서버는 이 기록을 서버에 저장을 해야 합니다. 이를 세션이라고 부릅니다. 대부분의 경우엔 메모리에 이를 저장하는데, 로그인 중인 유저의 수가 늘어난다면 어떻게 될까요? 서버의 램이 과부하가 되겠지요? 이를 피하기 위해서, 세션을 데이터베이스에 시스템에 저장하는 방식도 있지만, 이 또한 유저의 수가 많으면 데이터베이스의 성능에 무리를 줄 수 있습니다.
2. 확장성
세션을 사용하면 서버를 확장하는 것이 어려워집니다. 여기서 서버의 확장이란, 단순히 서버의 사양을 업그레이드하는 것이 아니라, 더 많은 트래픽을 감당하기 위하여 여러 개의 프로세스를 돌리거나, 여러 대의 서버 컴퓨터를 추가하는 것을 의미합니다. 세션을 사용하면서 분산된 시스템을 설계하는 건 불가능한 것은 아니지만 과정이 매우 복잡해집니다.
3. CORS (Cross-Origin Resource Sharing)
웹 애플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있습니다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 좀 번거롭습니다.
위와 같은 이유로 토큰을 사용하게 되었다.
2. 토큰 기반
1. 유저가 아이디와 비밀번호로 로그인을 합니다
2. 서버 측에서 해당 계정 정보를 검증합니다.
3. 계정 정보가 정확하다면, 서버 측에서 유저에게 signed 토큰을 발급해줍니다.
4. 여기서 signed의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있다는 것입니다
5. 클라이언트 측에서 전달받은 토큰을 저장해 두고, 서버에 요청을 할 때마다, 해당 토큰을 함께 6. 서버에 전달합니다.
7. 서버는 토큰을 검증하고, 요청에 응답합니다.
장점
1. 무상태(stateless)이며 확장성(scalability)
토큰은 클라이언트 사이드에 저장하기 때문에 완전히 stateless 하며, 서버를 확장하기에 매우 적합한 환경을 제공합니다. 만약에 세션을 서버 측에 저장하고 있고, 서버를 여러 대를 사용하여 요청을 분산하였다면, 어떤 유저가 로그인했을 땐, 그 유저는 처음 로그인했었던 그 서버에만 요청을 보내도록 설정을 해야 합니다. 하지만, 토큰을 사용한다면, 어떤 서버로 요청이 들어가던, 이제 상관이 없죠.
2. 보안성
클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않음으로 쿠키를 사용함으로 인해 발생하는 취약점이 사라집니다. 하지만, 토큰을 사용하는 환경에서도 취약점이 존재할 수 있으니 언제나 취약점에 대비해야 합니다
3. Extensibility (확장성)
여기서의 확장성은, Scalability 와는 또 다른 개념입니다. Scalability는 서버를 확장하는 걸 의미하는 반면, Extensibility 는 로그인 정보가 사용되는 분야를 확장하는 것을 의미합니다. 토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있습니다. 예를 들어서, 스타트업 구인구직 웹서비스인 로켓펀치에서는 Facebook, LinkedIn, GitHub, Google 계정으로 로그인을 할 수 있습니다.
토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 발급을 할 수 있습니다 (예를 들어서 로켓펀치에서 페이스북 계정으로 로그인을 했다면, 프로필 정보를 가져오는 권한은 있어도, 포스트를 작성할 수 있는 권한은 없죠)
4. 여러 플랫폼 및 도메인
애플리케이션과 서비스의 규모가 커지면, 우리는 여러 디바이스를 호환시키고, 더 많은 종류의 서비스를 제공하게 됩니다. 토큰을 사용한다면, 그 어떤 디바이스에서도, 그 어떤 도메인에서도, 토큰만 유효하다면 요청이 정상적으로 처리됩니다. 서버 측에서 애플리케이션의 응답 부분에 다음 헤더만 포함시켜주면 되지요.
Access-Control-Allow-Origin: *
이런 구조라면, assets 파일들(이미지, css, js, html 파일 등)은 모두 CDN에서 제공을 하도록 하고, 서버 측에서는 오직 API만 다루도록 하도록 설계할 수도 있지요.
5. 웹 표준 기반
토큰 기반 인증 시스템의 구현체인 JWT는 웹 표준 RFC 7519에 등록이 되어있습니다. 따라서 여러 환경에서 지원이 되며 (.NET, Ruby, Java, Node.js, Python, PHP …) 수많은 회사의 인프라스트럭쳐에서 사용되고 있습니다 (구글, 마이크로소프트 …)
도움이 된 블로그 : https://velopert.com/2350