Java_JWT

Minki CHO·2023년 1월 18일
0

CodeStates

목록 보기
23/43

JWT Json Web Token 이란?

:데이터를 안전하고 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식
:토큰 인증 방식에서 가장 범용적으로 사용됨
:JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명Sign한 메시지를 Web Token으로써 인증 과정에 사용함

JWT 종류

1) 액세스 토큰 Access Token
2) 리프레시 토큰 Refresh Token

1) 액세스 토큰 Access Token
:보호된 정보들(사용자들의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용

클라이언트가 처음 인증을 받게 될 때(로그인 시), Access Token과 Refresh Token 두가지를 받음
그러나 실제로 권한을 얻는 데 사용하는 토큰은 Access Token임

? 그러면 Access Token만 있으면 되는거 아닌가?
권한을 부여 받는 것에는 Access Token만 가지고 있으면 됨
but.
Access Token을 해킹당했을 때, 해커가 Access Token의 주인인 것처럼 서버에 여러가지 요청을 보낼 수 있음
그렇기 때문에 Access Token에 비교적 짧은 유효기간을 주어 탈취되더라도 오랫동안 사용할 수 없게 하는 것이 좋음
Access Token의 유효기간이 만료된다면 Refresh Token을 사용하여 새로운 Access Token을 발급받음(이때 사용자는 다시 로그인 인증할 필요 없음)

? Refresh Token도 탈취당한다면?
:유효기간이 긴 Refresh Token을 해킹당하면 Refresh Token을 이용해 Access Token을 다시 발급받을 수 있어 큰 피해 발생할 수 있음
:그래서 사용자의 편의보다 정보를 지키는 것이 더 중요한애플리케이션의 경우 Refresh Token 사용하지 않음

JWT 구조


:"."으로 나누어진 세 부분이 존재

1) Header 헤더
:이것이 어떤 종류의 토큰인지(지금 경우엔 JWT), 어떤 알고리즘으로 Sign할지 정의
:JSON Web Token이라는 이름에 맞게 JSON 포맷 형태로 정의함

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

:위 Json 객체를 base64방식으로 인코딩하면 JWT의 첫 부분 블록 완성
:typ : 토큰 타입을 지정
:alg : 해싱 알고리즘 지정

2) Payload 정보
:서버에서 활용할 수 있는 사용자 정보가 담겨있음
:어떤 정보에 접근 가능한지에 대한 권한을 담을 수 있고, 사용자 이름 등 필요한 데이터를 담을 수 있음
:민감한 정보는 담지 않는 것이 좋음

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

:위 Json 객체를 base64로 인코딩하면 JWT의 두 번째 블록 완성
:sub : 토큰 제목subject
:iat : 토큰이 발급된 시간(issued at), 이 값을 이용하여 토큰의 age가 얼마나 되었는지 판단 가능

3) Signature 서명
:base64로 인코딩된 첫번째, 두번째 블록이 완성되면,
:원하는 비밀 키(Secret Key)와 Header에서 지정한 알고리즘을 사용하여 Header와 Payload에 대해서 단방향 암호화를 수행함
:이렇게 암호화 된 메시지는 토큰의 위변조 유무를 검증하는데 사용됨
if.
HMAC SHA256 알고리즘(암호화 방법 중 하나)을 사용한다면 Signature은 아래처럼 생성됨

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

JWT 사용 예시

JWT는 권한 부여에 매우 유용함

if.
새로 다운받은 A라는 앱이 Gmail과 연동되어 이메일을 읽어와야 함
이 경우, 사용자는
1) Gmail 인증 서버에 로그인 정보(아이디, 비밀번호) 제공
2) 인증에 성공할 경우, JWT 발급받음
3) A 앱은 JWT를 사용해 해당 사용자의 메일을 읽거나 사용할 수 있음'

토큰 기반 인증 절차

1) 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보냄
2) 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 암호화된 토큰을 생성
-Access Token과 Refresh Token을 모두 생성
:토큰에 담길 정보Payload는 사용자를 식별할 정보, 사용자 권한 등이 될 수 있음
:Refresh Token을 이용해 새로운 Access Token을 생성할 것이므로 두 종류의 토큰이 같은 정보를 담을 필요는 없음
3) 토큰을 클라이언트에게 전송하면, 클라이언트는 토큰을 저장함
-저장하는 위치는 Local Storage, Session Storage, Cookie 등이 될 수 있음
4) 클라이언트가 HTTP Header(Authorization Header) 또는 쿠키에 토큰을 담아 request를 전송
-Bearer authentication 이용
5) 서버는 토큰을 검증하여 "이 서버에서 발급한 토큰이 맞네"라고 판단될 경우, 클라이언트의 요청을 처리한 후 응답 발송

profile
Developer

0개의 댓글