인증 인가 방식 비교

📌 서버기반 인증(session)

---

• 서버에 세션을 만들어 사용자에 대한 정보를 저장, 관리 한다.
• 사용자 브라우저(클라이언트)에는 세션ID 를 저장하는 쿠키가 생성된다. 서버는 이 세션ID를 통해 사용자를 식별한다.
• 클라이언트가 어떤 요청을 보낼 때마다 헤더에 cookie에 대한 세션 id를 담아 전송
• 서버는 클라이언트 에서 보낸 세션id를 대조해 인증 상태를 확인함.

장점

• 쿠키가 노출되더라도 쿠키 자체(세션ID)는 유의미한 값을 가지고있지 않다.
• 사용자들은 각각 고유의 세션ID값을 발급받게 되어, 서버에서 쿠키 값을 받았을 때 회원정보를 하나하나 확인할 필요없다.

단점

• 쿠키가 탈취되어 서버에 요청을 보낸다면 서버는 인증된 사용자인지, 해커인지 구별할 방법이 없다.

 

📌 토큰기반 인증(JWT)

---

• JSON Web Token 의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다.
• 사용자는 Access Token 을 헤더에 실어 서버로 보낸다.
• JWT의 구조
  • 헤더(Header) - 일반적으로 토큰의 유형과 암호화 알고리즘 두가지 정보를 JSON 형태로 담고 있다.
  • 페이로드(Payload) - 사용자의 정보 혹은 데이터 속성 등을 나타내는 클레임 이라는 정보 단위로 구성된다. 클레임은 각각 등록된 클레임, 공개 클레임, 비공개 클레임 으로 구성되어 있다.
  • 서명(Signature) - 특정 암호화 알고리즘을 사용하여, Base64 인코딩된 헤더와, 페이로드, 비밀키를 이용하여 암호화한다.

장점

• 서버기반 인증 방식의 경우 별도의 저장소 관리가 필요하다. 하지만 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요없다. ( 서버의 확장과 유지/보수 에 유리할거라 생각된다)

단점

• 이미 발급된 JWT에 대해서는 유효기간이 지날때까지 관리가 불가능하다.
• Payload의 정보가 제한적이다.(누구나 볼 수 있기 때문에 중요한 정보를 넣을 수 없다)
• JWT의 길이가 길어 서버의 자원 낭비가 발생할 가능성이 높다. ← 서버인증방식에 비해 자원낭비가 상대적으로 높다

Refresh Token

• 토큰 기반 인증 방식의 보안성을 높이기 위해 탄생
• 처음 로그인 시 Refresh Token과 Access Token 을 동시에 발급한다
• AT 토큰의 경우 만료시간 (5분에서 15분사이) 을 적게 주는대신 RT토큰의 만료시간을 길게 준다.
• AT 토큰이 만료될 경우 RT토큰을 사용해 AT토큰을 재발급 받을 수 있다.

 

📌 Reference

• https://hudi.blog/self-made-jwt/
• https://velog.io/@kingth/서버-인증-방식세션쿠키-토큰
• https://docs.login.xyz/general-information/siwe-overview
• https://effectivesquid.tistory.com/entry/Base64-인코딩이란