[BACKEND]Token

Token

세션기반 인증 -> 서버에 유저정보를 담는 방식 -> 서버 부담을 클라이언트에게 넘기기 위해 고안

대표 토큰기반 인증 - JWT(JSON Web Token)

토큰 - 클라이언트가 가지고 있는 인증 마패(암호화 되어 있음)

JWT 구조

1. Header
   • 어떤 종류의 토큰?
   • 어떤 알고리즘으로 암호화?

     {
       "alg": "HS256"
       "typ": "JWT"
     }
     

2. Payload
   • 유저 정보
   • 권한 부여 받음?
   • 기타 필요한 정보

     {
       "sub": "soneInformation"
       "name": "phillip"
       "iat": "151623391"
     }
     

3. Signature
   • Header, Payload를 base64인코딩한 결과
   • salt값의 조합으로 암호화된 값
   • HMAC SHA256 알고리즘을 사용한다면 Signature는

     HMACSHA256(
     base64UrlEncode(header) + "." + basbase64UrlEncode(payload),
     secret
     );
     

토큰기반 인증 절차

1. 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청
2. 아이디/비밀번호 일치 확인, 클라이언트에게 보낼 토큰 생성
   • access/refresh 토큰 모두 생성
     • payload는 유저 식별 정보, 권한 부여 카테고리가 될 수 있음
     • 액세스 토큰 - 실제 출입용
     • 리프레시 토튼 - 재발급용
     • 두 토큰이 같은 정보를 담을 필요는 없음
3. 서버가 토큰을 보내고, 클라이언트는 저장
   • 저장 위치는 Local Storage, Sesstion Storage, Cookie 등 다양
4. 클라이언트가 HTTP헤더(Authorization헤더) 또틑 쿠키에 코튼을 담아 보냄
   • 쿠키에 리프레시 토큰을 헤더, 또는 엑세스 토큰을 바디에 담는 등 다양한 방법 구현 가능
   • Authorization헤더 사용시 Bearer Authentication 이용 https://learning.postman.com/docs/sending-requests/authorization/#bearer-token

토큰기반 인증 장점

1. Statelessness & Scalability(무상태성 & 확장성)
   • 서버가 클라이언트 정보 저장 필요 없음(토큰 해독 가능만 확인)
   • 클라이언트는 새로운 요청마다 토큰을 헤더에 포함
     • 서버가 여러개면 같은 토큰으로 여러 서버에서 인증 가능, 세션 방식이라면 모든 서버가 해당 유저 정보 공유 필수
   • 안전
     • 암호화한 토큰 사용, 암호화 키 노출 필요 없음
   • 어디서나 생성 가능
     • 토큰을 확인하는 서버가 토큰 생성을 하지 않아도 됨
     • 토큰 생성용 서버, 다른 회사에 외주 등 가능
   • 권한 부여에 용이
     • 토큰의 Payload 안 특정 정보에 접근 가능한 지 설정 가능
       • e.g. 사진과 연락처 사용 권한만 부여