토큰과 세션, Stateful과 Stateless

개요

새롭게 스프링 포팅 작업을 진행하면서, 인증 부분 구현을 맡게 되었습니다.

기존에는 간단하게만 이해하고 있던 부분들이었는데, 더 명확하게 짚을 필요가 있지 않을까 하는 생각이 문득 들었습니다.

현재 우리가 사용하는 인증 방식들에 대한 이해와 관련한 개념들에 대한 학습이 필요하다고 느꼈고, 이것들을 정리해보고자 합니다.

---

인증과 인가

인증(Authentication)과 인가(Authorization)는 다른 의미입니다.

 

인증은 접근할 수 있는 사용자인지 자격을 1차적으로 검증하는 것입니다. 42의 경우에는 42 OAuth(인트라 로그인)을 통과하는 사람들이 1차적으로 우리가 제공하는 서비스에 접근할 수 있는 ‘인증된 사용자’일 것입니다.

 

인가는 접근 권한을 식별하는 것입니다. 1차적으로 우리 서버에 접근할 수 있다고 하더라도, 권한에 따라 접근할 수 있는 리소스(정보)가 다르다면 그 권한에 따라 인가해주어야 하는 것입니다.

비행기를 예로 들어보겠습니다.

• 인증 - 여권과 비행기 표가 확인되어야 비행기를 탈 수 있다.
• 인가 - 비행기 표에 적힌 좌석 등급(권한)에 따라 앉을 수 있는 자리가 다르다.

즉, 인증은 누구인지 확인하는 것이고 인가는 무엇을 할 수 있는지 알아보는 것입니다.

그리고 이러한 인증, 인가를 웹 어플리케이션에서 구현하는 방법에는 주로 세션(Session)과 토큰(Token)을 통한 방식이 있습니다.

---

세션

먼저 세션에 대해서 알아보겠습니다. 세션의 영영풀이는 다음과 같습니다.

a period of time or meeting arranged for a particular activity
특정 활동을 위해 정해진 모임이나 기간

인증에서 세션은 인증 및 권한 부여 정보를 포함하여 사용자 데이터를 저장하기 위한 서버측 메커니즘입니다.

사용자가 로그인하면 서버에 세션이 생성되고, 고유한 세션 ID가 쿠키 형태로 클라이언트에 전송됩니다.

클라이언트는 각 후속 요청과 함께 이 ID를 전송하여 서버가 사용자의 세션 데이터를 검색하고 응답을 제공할 수 있도록 합니다.

세션을 이용한 인증 방식은 다음과 같이 나타납니다.

• 사용자가 유효한 로그인을 합니다.
• 사용자의 세션 ID와 그 사용자에 대한 식별 정보를 key:value 형태로 서버가 기억합니다.
• 이에 맞춰서 사용자는 본인이 서버에게서 발급받은 세션 ID를 요청할 때에 전송하고, 서버는 key인 세션 ID를 통해 해당 유저임을 확인, 정보를 제공하는 것입니다.

---

토큰

토큰(Token)에 대한 영영 뜻풀이는 다음과 같이 쓰여있습니다.

something that you do, or a thing that you give someone, that expresses your feelings or intentions, although it might have little practical effect
실질적으로 효과가 없을지라도, 자신의 감정이나 의도를 표현하는 행동을 누군가에게 전달하는 것

인증에서 토큰은 제한된 리소스에 대해 일정 기간 동안 접근할 수 있는 권한을 캡슐화한 것입니다.

토큰은 일반적으로 의미를 알 수 없는 임의의 문자열 형태로 사용자에게 발급됩니다.

토큰을 이용한 인증 방식은 대체로 다음과 같이 나타납니다.

• 유저가 인증을 수행하여 성공하면, 서버는 토큰을 발급해줍니다.
• 유저는 앞으로 이 토큰을 가지고 있고, 매번 리소스에 대한 접근을 요청할 때 token을 서버에게 전달하여 본인이 인증된 사용자임을 나타냅니다.
• 서버는 유저로부터 전달받은 토큰을 본인들이 발급한 토큰이 맞는지, 만료되지는 않았는지 등을 따져 유효성을 검사하고, 유효한 토큰인 경우 접근을 허가합니다.

왜 ‘대체로’라고 얘기했을까요? 그 이유는, 감히 제가 판단하건대, 그리고 저를 포함한 대부분의 사람들이 이해하는 토큰을 이용한 인증 방식은 위와 같은 방식이라고 생각하기 때문입니다. 그렇다면 어떤 지점에서 의미가 나뉘는 걸까요?

 

토큰은 의미의 단위임은 이미 설명했으니, ‘유저는 앞으로 이 토큰을 가지고 있고’라고 말했던 부분에 주목하여 설명하겠습니다.

---

Stateful vs Stateless

유저가 토큰을 가지고 있다는 것은 무슨 의미일까요?

이것은 유저(클라이언트)에 대한 특정 정보가 서버가 아닌 유저 측에 저장되어 있음을 뜻합니다.

이를 무상태(stateless)라고 할 수 있습니다.

 

만약 서버측에 저장되어 있다면 이는 상태유지(stateful)를 뜻합니다.

즉, stateless와 stateful을 구분하는 기준은 ‘클라이언트의 정보가 서버에서 관리되는가?’로 생각해볼 수 있습니다.

stateful과 stateless한 인증 방식의 장단점

stateful한 방식으로 인증하는 방법의 장점은 다음과 같습니다.

• 단순하다 - 구현과 관리가 stateless한 방식을 구현하는 것보다 상대적으로 간단합니다.
• 유연하다 - 여러 군데에서 사용될 수 있는 유저에 대한 정보를 서버가 관리하고 있기 때문에, 필요한 정보들에 대해 삭제, 추가할 수 있습니다.
• 관리하기 용이하다 - 인증된 사용자에 대한 정보 자체를 서버에서 관리하므로, 해당 사용자에 대한 제한, 접근 권한 설정 등에 대해서 서버가 원하는 시점에 관리할 수 있습니다.

한편 단점은 다음과 같습니다.

• 저장해야만 한다 - 서버가 인증된 사용자에 대해 알고 있어야 하므로, 트래픽이 많거나 사용자가 많은 경우에는 메모리 및 리소스를 많이 사용할 수 있습니다.
• 확장하기 어렵다 - 인증에 대한 정보를 서버 안의 분산되어 있는 여러 서비스들이 사용하는 경우에, 서버가 관리하는 하나의 풀(pool)만 고려한다면 여러 서비스가 하나의 데이터를 일관되게 공유하거나 복제해야 하므로 확장성이 저하될 수 있습니다.

stateless한 방식으로 인증하는 방법의 장점은 다음과 같습니다.

• 상대적으로 가볍다 - stateful하게 관리하는 경우 서버가 가지고 있어야하던 부담들을 각각의 client가 작은 크기로 부담하게 되므로, 서버가 사용하게 되는 메모리와 리소스가 감소합니다.
• 확장하기 쉽다 - 반드시 서버가 갖고 있는 세션을 거치지 않아도 되므로 분산되어 있는 서비스들에 적용하기 용이합니다.
• 제3 서비스와의 호환성이 높다 - 단순히 서버측에서만 사용할 수 있는 방식이 아닌, 다른 플랫폼(카카오, 애플, 네이버, 구글 …)들을 통해서도 인증을 구현할 수 있게 됩니다.

한편 단점은 다음과 같습니다.

• 관리가 힘들다 - 정보 자체를 클라이언트에서 관리하기 때문에 안전하게 클라이언트에게 심어줄 수 있어야 하는 것과, 만료기한 등 - 보안과 관련한 문제들을 적절히 수행할 수 있어야 합니다 - 인증을 위한 정보의 통제 자체가 클라이언트에게 있으므로 관리가 힘들 수 있습니다.
• 탈취에 대해 취약하다 - HTTP를 통한 요청으로 인증 정보를 주고 받지만, 이 도중 탈취되는 경우에 클라이언트가 보유하던 정보들이 노출 될 수 있습니다.
• 제3 서비스를 이용한 구현이 어렵다 - 외부 서비스들과 호환하고자 하는 경우에 대해 별도의 전략이나 추가적인 학습이 요구되므로 stateful한 것에 비해 상대적으로 구현이 어렵습니다.

---

JWT

그렇다면 위에서 말했던 대체로 인증에 쓰이는 방식의 토큰은 무엇일까요?

그것은 바로 stateless token, JWT(JSON Web Token)입니다. 이름에서 볼 수 있듯, JWT는 웹에서 사용하는, JSON 형식으로 정보를 담고 있는 토큰입니다.

JWT의 구조는 위 사진에서 보이는 것 처럼 왼쪽이 임의의 문자열로 이루어진 토큰의 모습이고, 그 오른쪽은 Header, Payload, Signature 순으로 구성되어 있습니다.

 

Header의 경우 이 토큰(JSON 형식)이 어떠한 알고리즘으로 암호화 되어 있는지에 대한 정보를 담고 있습니다.

Payload는 이 토큰이 담고자 하는 정보들을 담고 있습니다.

Signature는 Header에 나타나 있는 방식을 통해 유효한 토큰인지 확인할 수 있는 암호화된 인증 정보를 담고 있습니다.

 

위 사진을 통해 Payload를 보시면, 제 인트라 고유 id, email, intra id, 블랙홀 기간 등에 대한 정보들을 담고 있는 것을 알 수 있습니다.

즉, 토큰이 서버가 필요한 유저에 대한 정보를 담고 있으므로(== 서버가 본인이 필요한 유저 정보를 관리하고 있지 않으므로) stateless token이라고 생각할 수 있습니다.

 

여기서 짚고 넘어가야 할 부분은, 일반적으로 JWT는 암호화된 정보를 담은 토큰이 아닙니다. 적어도 정보 자체에 대해서는 암호화 하지 않고 그대로 Payload에 담되, 그것에 대한 유효성 여부(변조되었는지)등을 서버측에서 감지하기 위한 서버의 secret_key를 통한 암호화된 signature에 대한 정보를 담고 있을 뿐입니다.

⇒ 제 토큰을 그대로 들고가서 jwt.io에 입력하면 그대로 제 정보들을 담은 payload가 나타나는 것도 그 이유입니다.

(여러분도 개발자 도구를 키셔서 애플리케이션 - 쿠키 or 로컬 스토리지에 있는 토큰을 jwt.io에 입력하시면 볼 수 있습니다)

---

stateful token?

그렇다면, token이라면 다 stateless할까요? 그것은 아닙니다.

인증된 사용자에 대한 정보를 어디서 관리하느냐에 따라 stateful과 stateless가 나뉘는 것을 고려하였을 때, stateful token이라고 한다면 마치 유저에 대한 정보를 토큰으로 서버가 관리하는 것처럼 생각이 들 수 있습니다. 하지만, 이것은 아닙니다.

 

저희는 이미 stateful token에 대해 얘기했습니다. 바로 session ID입니다.

session ID가 있다는 것이 의미하는 바는, 인증된 사용자에 대한 정보를 서버에서 관리하는 것으로 stateful하게 인증을 관리하고 있다는 것입니다. 이 경우, stateful한 인증에 대해서 본인이 인증된 사용자임을 증명하고자 하는 의도를 담은 최소 단위, 즉 token인 session ID가 stateful token이 되는 것입니다.

 

이런 경우를 생각해본다면, 단순히 token == stateless라고 하는 것은 좋지 않은 생각이라고 할 수 있을 것 같습니다.

---

맺음말

인증과 인가, stateless와 stateful, 그리고 토큰과 세션의 의미에 대해서 살펴봤습니다.

웹 애플리케이션의 핵심이자 기본인 부분들이다보니, 용어의 사용에 있어서 개념적인 이해가 더 명료해져야하고 혼동되지 않아야한다고 생각합니다.

제 나름대로의 이해에 따른 정리이므로 틀린 부분이 있다면 꼭 말씀해주시기 바랍니다. 감사합니다.

---

참고자료

토큰 기반 인증이란? 인증 토큰의 종류와 JWT의 이점 | Okta Identity Korea

Session & Token