토큰(Token)이란? 쿠키/세션, 토큰 기반 인증(+JWT)

로그인/회원가입 인증 프로레스를 알아보다가

토큰 개념을 잘 모르겠어서 이번 기회에 확실히 잡고 가보려고 한다!

 

 

 

하지만 그 전에! 쿠키/세션이 뭔지 잘 모르겠다면..?

아래 포스팅 보고 오는걸 추천!!!

쿠키(Cookie)/세션(Session), 캐시(Cache)

잘 알고 있다면 패스! 총총,,,

 

 

 

 

 

 

🔎 토큰이란?

서버가, 각각의 클라이언트를 누군지 정확히 구별할 수 있도록 유니크한 정보를 담은 암호화 데이터이다.

 

 

💡 토큰을 왜 써?

유저 구별이 가능해야, 유저의 권한에 맞는 정확한 기능을 응답할 수 있기 때문이다!

( 사용자 구분 및 정보 유출 방지 )

 

보통 서버가 클라이언트 인증을 확인하는 방식은 대표적으로 쿠키, 세션, 토큰 3가지 방식이 있다.

 

 

 

 

🏷️ 쿠키 기반 인증

* 쿠키란? Key-Value 형식의 문자열 덩어리

 

클라이언트가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해

클라이언트의 브라우저(PC)에 설치되는 작은 기록 정보 파일이다.

각 사용자마다 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다.

 

하지만 쿠키는 보안에 취약하다. 요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작당할 위험이 존재한다.

쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없고, 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

 

이 때문에 쿠키 기반 인증 방식은 더 이상 많이 사용되지 않지만

쇼핑몰의 장바구니 등 여러 옵션을 장기 보관하는 용도로 사용되고 있다.

 

 

 

 

---

 

 

 

🏷️ 세션 기반 인증

이러한 쿠키의 보안적인 이슈 때문에 나온 것이 세션 기반 인증 방식이다.

세션 기반 인증은 서버에 유저 정보를 담는 인증 방식이다.

서버에서 민감하거나 제한된 정보를 요청할 때마다 보내도 괜찮은지 확인하기 위해 세션값과 일치하는지 확인한다.

 

그러나 매 요청마다 DB를 살펴보기도 불편하고 세션은 서버당 하나만 가진다.

다른 서버에 요청을 보낸다면 또 세션 값을 만들어야 하는 복잡성이 생긴다. (분산 시스템일 때 관리가 어려움)

서버의 부담을 해소하고자 토큰 기반 인증방식이 도입되었다.

 

 

---

 

 

🏷️ 토큰 기반 인증

토큰 기반의 인증 시스템은 인증받은 사용자들에게 토큰을 발급하고,

서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 한다.

 

이러한 시스템에서는 더 이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고

클라이언트 측에서 들어오는 요청만으로 작업을 처리한다.

즉, 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 구조를 갖는다.

 

이러한 토큰 기반의 인증 방식을 통해 수많은 문제점들을 해결 할 수 있는데,

대표적으로 사용자가 로그인이 되어있는지 안되어있는지 신경 쓰지 않고 손쉽게 시스템을 확장할 수 있다.

JWT(JWON Web Token)이 대표적이다.

 

 

---

 

 

🔐 JWT (JSON Web Token)

* JWT란? 인증에 필요한 정보들을 암호화시킨 토큰을 의미

 

JWT 기반 인증은 JWT토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

 

이해가 잘 안된다면 아래 인증 과정을 살펴보자!

 

1. 사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청한다.

2. 서버에서 클라이언트로부터 인증 요청을 받으면, 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣는다.

3. JWT를 생성해 이를 쿠키에 담아 클라이언트에게 발급한다.

4. 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장한다. (쿠키나 다른 곳에 저장할 수도 있음) API를 서버에 요청할 때 Authorizationn header에 Access Token을 담아서 보낸다.

5. 서버는 클라이언트가 Header에 담아서 보낸 JWT가 내 서버에서 발행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과 시켜주고 아니라면 통과시키지 않는다.

6. 인증이 통과되었다면 Payload에 들어있는 유저의 정보들을 select 해서 클라이언트에게 돌려준다.

7. 클라이언트가 서버에 요청을 했는데, 만일 Access Token의 시간이 만료되었다면 클라이언트는 Refresh Token을 이용해서 서버로부터 새로운 Access Token을 발급받는다.

 

 

엥 근데 Access Token 이랑 Refresh Token은 뭐야?

 

Access Token이랑 Refresh Token은 둘 다 똑같은 JWT인데,

다만 토큰이 어디에 저장되고 관리되느냐에 따른 사용 차이일 뿐이다!

 

 

 

🔒 Access Token

클라이언트가 갖고 있는 실제의 유저 정보가 담긴 토큰으로,

보호된 정보들(유저 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용한다.

클라이언트가 처음 인증을 받게 될 때 (로그인 시), Access Token, Refresh Token 둘 다 받지만,

실제로 권한을 얻는 데 사용하는 토큰은 Access Token이다.

 

하지만 제 3자에게 탈취당할 경우 보안에 취약하다.

유효기간이 짧은 토큰의 경우 사용자는 로그인을 자주 해서 새롭게 토큰을 발급받아야 한다.

그렇다고 유효기간을 늘리자니 탈취당하면 보안에 더 취약해진다.

 

 

 

🔑 Refresh Token

처음에 로그인했을 때 Access Token과 동시에 발급된다.

긴 유효기간을 가지면서 Access Token이 만료 됐을 때 새로 발급해 주는 열쇠가 된다.

해당 토큰은 보통 데이터베이스에 유저 정보와 같이 기록.

 

 

 

 

근데 그럼 혹시 SNS로그인은 어떤 방식으로 동작되는 걸까?

 

 

 

간단히 말하면 OAuth 2.0 + 서버 인증(세션/쿠키, 토큰 기반 인증)으로 구성된다고 한다.

*OAuth 2.0이란? 외부 서비스의 인증 및 권한 부여를 관리하는 범용적인 프로토콜

 

 

 

SNS로그인 프로세스에 대해 더 자세히 알고싶다면 아래 블로그 참고. 설명 기깔남!

📌 https://tansfil.tistory.com/60?category=475681 

 

 

 

 

 

 

📌 쿠키/세션, 토큰 기반 인증 참고 : https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC