Backend/Auth
토큰 기반 인증(JWT)
괴발새발자
2022. 3. 2. 00:02
JWT란?
- Json Web Token. JSON 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰
- 세션 기반 인증 (서버(혹은 DB)에 유저 정보를 담는 방식)에 대한 부담.
- 대표적인 토큰 기반 인증 → JWT (JSON Web Token)
- 토큰의 특징 : 유저 정보를 암호화한 상태로 담을 수 있고, 암호화했기 때문에 클라이언트에 담을 수 있다
JWT의 종류
- Access Token : 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용. 짧은 유효기간
- Refresh Token : Access Token의 유효기간이 만료되었을 때 사용. 새로운 Access Token 발급 받음. 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 Refresh Token을 사용하지 않기도 함.
JWT의 구조
Header
- 어떤 종류의 토큰인가?
- 어떤 알고리즘으로 암호화 하는가? (예시에서는 base64)
{"alg":"HS256", "typ":"JWT"}
Payload
- 유저 정보
- 권한을 부여받았는가?
- 기타 필요한 정보. 민감한 정보는 되도록 담지 않는 것이 좋음
{"sub":"someInformation". "name":"phillip", "iat":151623391}
Signature
- Header, Payload를 base64인코딩한 값과 salt 값의 조합으로 암호화된 값
HMACSHA256( base64UrlEncode(header)+"."+ base64UrlEncode(payload), secret)
aaaaaa.bbbbbb.cccccc [Header.Payload.Signature]
토큰기반 인증 절차
- 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청 보냄
- 아이디/비밀번호가 일치하는지 확인, 클라이언트에게 보낼 Signature된 토큰 생성
- access/refresh 토큰을 모두 생성
- 토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처, 기타 등등) 일 수 있음
- 두 종류의 토큰이 같은 정보를 담을 필요는 없음
- access/refresh 토큰을 모두 생성
- JWT토큰을 클라이언트가 저장 : 로컬 스토리지, 쿠키, 리액트 스테이트 등
- 클라이언트가 HTTP헤더(authorization 헤더)에 토큰을 담아 보냄
- 서버가 토큰을 해독하여 발급 토큰이 맞을 경우 클라이언트 요청을 처리한 후 응답을 보냄
토큰 기반 인증의 장점
- Stateless & Scalability(무상태성과 확장성)
- 서버는 클라이언트에 대한 정보를 저장할 필요가 없음. 토큰 해독만 판단 → 서버, 데이터베이스 부담 덜음
- 클라이언트는 토큰을 헤더에 추가함으로써 인증 절차 완료 → 하나의 토큰으로 여러 서버 인증 가능. 앱의 확장 가능
- 안정성
- 암호화된 토큰 사용, 암호화한 키를 노출할 필요 없음
- 어디서나 생성 가능
- 토큰을 확인하는 서버가 꼭 토큰을 만들지 않아도 됨(토큰 생산자-다른 서버, 다른 회사와 확인자가 달라도 됨)
- 권한 부여에 용이
- 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정의 가능
- 예) 사진과 연락처에만 사용 권한 부여 / 사진 권한만 부여 / 연락처 권한만 부여
이외 참조하면 좋은 사이트
https://it-eldorado.tistory.com/165
[Web] 인가 (Authorization) : JWT (JSON Web Token), 리프레시 토큰
1. 인증 (Authentication) vs 인가 (Authorization) 본 포스팅에서 인증에 관한 내용을 다루기 전에, 먼저 인증과 인가의 차이를 알아보자. 먼저, 인증(Authentication)이란 서비스로부터 일정 권한을 부여받은.
it-eldorado.tistory.com