저번 포스팅에서 JWT의 개념에 대해 살펴보았습니다!
그래서 든 의문 여러가지 token
은 왜 사용하며, 어떻게 담을까? token
에 대해 더 깊이 고민해보게 되었습니다 🔎
우선, 가장 큰 이유는 HTTP의 특성때문입니다. HTTP는 연결 지향 프로토콜인 TCP 기반임에도 불구하고, 대표적인 비연결 지향 프로토콜입니다. 따라서 한 번의 요청-응답 사이클이 완료되면 연결을 종료하기 때문에, 동일한 클라이언트가 요청을 아무리 많이 하더라도 프로토콜은 모두 처음보는 것 마냥 인지합니다! 이를 stateless 하다고 표현하기도 합니다.
stateful해지기 위해서, 즉, 상태를 유지하기 위해 많은 시도들이 있었습니다. 예를 들면, 우리가 잘 아는 세션이나 쿠키가 있습니다. 이는 대표적인 서버 기반 인증 시스템입니다. 이 시스템은 인증에 필요한 특정 유저 정보를 서버 혹은 데이터베이스에 저장할 수밖에 없습니다. 따라서, 서버나 데이터베이스의 부담이 증가하겠죠? 😥 또한, CORS (Cross-Origin Resource Sharing)의 문제도 존재합니다. 웹 어플리케이션에서 세션을 관리 할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있습니다. 따라서 쿠키를 여러 도메인에서 관리하는것은 좀 번거롭습니다.
그러나 토큰 기반 인증 시스템은 stateless 합니다. 무상태. 즉 상태유지를 하지 않는다는 것이죠. 이 시스템에서는 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않습니다. 서버의 부담이 감소할뿐만 아니라 보안성도 높고, 여러 플랫폼 및 도메인에서 적용가능하다는 장점이 있습니다! 또한, 대표적인 토큰 기반 인증 시스템인 JWT
는 웹 표준으로서, 많이 이용되고 있습니다.
우리는 토큰이 유저 인증을 위해 아주 효과적인 도구라는 것을 알았습니다. 유저를 인증할 수 있는 어떤 값을 토큰📦에 담겠습니다. 그렇다면! 토큰은 HTTP의 어디에 담아서 전달해야 할까요? 인증 정보는 표준적으로 Authorization header
에 담습니다. 그 형태를 자세히 살펴보자면, 다음과 같습니다.
header
내에 Authorization
Key의 Value 값으로서 우리는 인증 스키마를 담습니다. 이때, 인증 스키마는 type
credential
로 이루어지는데요. type
은 인증 방식을 의미하며, 대표적으로 Bearer
이 있습니다. credential
은 인증정보, 즉, 실질적으로 우리가 보내고자 하는 유저의 인증정보입니다. 대표적으로 access token
(위 그림의 '2B-LtDr4UURb87K' 부분)의 값이 있겠네요!
type
의 더 많은 종류가 궁금했는데, POSTMAN을 참고했을때, 다음과 같은 type
이 있는 것 같습니다.
이번에는 토큰 인증 방식이 왜 필요한지, 어떻게 토큰을 통해 인증 정보를 담는지 살펴보았습니다! 무작정 token header
를 만들어서 보내곤 했는데, 이번 기회에 표준을 잘지키며 개발할 수 있겠습니다!
어썸한 글 감사합니다 ^_^