로그인

• 미들웨어를 활용.
  • 미들웨어: 공통 서비스 및 기능을 어플리케이션에 제공. 서비스의 모든 url 요청에 대하여 공통적인 로그인 미들웨어를 둘 수 있음
• HTTP 프로토콜은 상태없음(stateless)한 특징을 가지고 있기에, 클라이언트가 서버에 요청 시 서버는 해당 요청에 대한 응답을 생성하고, 클라이언트의 상태를 유지하지 않음 -> 로그인 상태 유지 how?
• 세션 기반 인증과 토큰 기반 인증 방식이 존재. 세션은 서버에 상태를 저장하여 관리하고 토큰은 클라이언트에 상태를 저장하여 서버와 통신

1. 세션 기반 인증

용어 정리

• 세션: 서버와 클라이언트간의 연결이 활성화된 상태
• 세션ID: 웹 서버 혹은 DB에 저장되는 클라이언트에 대한 유니크한 ID

세션 기반 로그인 프로세스

• 사용자 로그인 시 서버에서 세션 ID를 생성하고 세션ID를 쿠키로 설정해서 클라이언트에 전달
• 클라이언트는 이 세션 ID를 쿠키에 저장하여 보관
• 이후 클라이언트가 서버에 요청을 보낼 때마다 세션 ID를 쿠키에 담아 함께 전송하여 로그인 상태를 서버에서 확인
  => 세션을 사용하여 로그인 상태가 유지

단점

• 서버 메모리 과부하 및 DB 오버헤드 (cost 증가) 발생 가능성 존재

2. 토큰 기반 인증

정의

• 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청할 때 헤더에 (Authorization 또는 Cookie) 토큰을 함께 보내도록 하는 방식으로 인증 정보를 서버나 세션에 유지하지 않고 클라이언트측에서 들어오는 요청만으로 작업을 처리 -> stateless 한 구조를 가짐
• 토큰은 주로 JWT 토큰이 사용된다

JWT 토큰의 구성

JWT = Json Web Toekn - 헤더, 페이로드, 서명으로 구성

Header

• 토큰 유형과 서명 알고리즘 포함, base64로 인코딩된다

Payload

• 유저의 id, pw 같은 데이터, 토큰 발급자, 유효기간. base64로 인코딩된다

Signature

• (인코딩된 header + payload) + 비밀키를 기반으로 헤더에 명시된 알고리즘으로 다시 생성한 서명값
• 토큰의 무결성 보장

장점

• 상태를 서버에 저장하지 않고 클라이언트에게 전송하므로 확장성이 용이
• JSON 상태로 데이터를 전송하기에 직렬화, 역직렬화가 쉽고 가벼움

단점

• 토큰이 탈취되면 내용이 노출 -> access, refresh 토큰의 필요성
• 토큰의 크기가 커질 경우 서버 과부하 발생 가능성 존재

Access 토큰과 Refresh 토큰

• Access 토큰은 짧은 수명을 가지며 클라이언트가 서버에 요청 시 (header에 포함) 사용됨
• Refresh 토큰은 Access 토큰이 만료된 경우 다시 access token을 발급받기 위해 사용되며, 더 긴 수명을 가짐
• access 토큰의 수명이 짧아야 해커의 탈취 위험 줄어든다

주의사항

• Bearer 를 token 앞에 붙여서 토큰 기반 인증방식이라는 것을 알려주어야 한다
• https 를 사용해야 한다
• 수명이 짧은 access token을 발급해야 한다
• url에 토큰을 전달하지 말아야 한다

---

REF