SEB_BE_43 / 23.03.20 회고

오늘

• JWT

JWT (JSON Web Token)

토큰 기반 자격 증명 방식이다.
= 인증된 사용자의 정보를 토큰에 저장하고, 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근할 수 있게 하는 방식.

JWT = JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명한 메시지를 Web Token 으로 인증 과정에 사용한다.

특징

- 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.
- 생성된 토큰을 HTTP 헤더에 포함해 Request 전송 시, 인증된 사용자인지 증명하는 수단으로 사용.
- 토큰 내에 인증된 사용자 정보 등을 포함하고 있으므로 세션 증명 방식에 비해 많은 네트워크 트래픽을 사용한다
- CSR 방식에 적합하다.

종류

• Access Token(액세스 토큰)

• Refresh Token(리프레시 토큰)

Access Token
보호된 정보들(연락처, 이메일, 사진..등) 에 접근 할 수 있는 권한 부여에 사용한다.

클라이언트가 처음 인증을 받게 될 때(로그인 할 때) 두가지의 토큰 모두 받는다. 하지만 실제로 권한을 얻는 데 사용하는 토큰은 Access Token 이다.

Refresh Token
Access Token 의 유효기간이 만료 되었을 때 새로운 Access Token 을 발급 받을 수 있도록 해준다.
✔️ 이 때 사용자는 다시 로그인을 할 필요가 없다.

구조

. 을 기준으로 3 부분으로 나눠진다.

Header

어떤 종류의 토큰인지, 어떤 알고리즘으로 사인할지 정의한다.

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

Payload

서버에서 사용 할 수 있는 사용자의 정보가 담겨있다. 
(민감한 정보는 담지 않는 것이 좋다)

{
	"sub" : "somInformation",
    "name" : "phillip",
    "iat" : 151623392
}

Signature

Signature에서 원하는 비밀키 와 Header 에서 지정한 알고리즘을 이용하여 
Header와 Payload 에 대해서 단방향 암호화를 수행한다.
이렇게 암호화된 메시지는 토큰의 위변조 유무를 검증하는 데 사용한다.

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

인증 절차

1. 클라이언트가 서버에 Username, Password 를 담아 로그인 Request 요청

2. 서버는 Username, Password 가 일치하는지 확인 후 암호화 된 토큰 생성.
   Access Token과 Refresh Token 모두 생성.
   토큰에 담길 정보(payload)는 사용자를 식별할 정보, 사용자의 권한 등.
   Refresh Token을 이용해서 Access Token을 생성 할 것이므로 동일한 정보를 담을 필요 x

3. 클라이언트에게 전송. 클라이언트는 토큰을 저장.
   저장 위치는 Local Storage, Session Storage, Cookie 등.

4. 클라이언트가 HTTP Header 또는 Cookie 에 토큰을 담아 요청 전송.

5. 서버에서 토큰 검증 하여 발급해준 토큰이 맞을 경우 클라이언트에게 응답 보내줌.

장단점

장점

- 상태를 유지하지 않고, 확장에 용이한 애플리케이션을 구현하기 용이하다.
	▫️ 서버는 클라이언트에 대한 정보를 저장할 필요가 없다.
    ▫️ 클라이언트는 Request 를 전송할 때마다 토큰을 헤더에 포함시키면 된다.
    	▫️ 여러대의 서버를 이용 서비스라면 하나의 토큰으로 여러 서버에서 인증이 가능하기 때문에 유용하다.
      
-  클라이언트가 요청을 전송할 때마다 자격 증명 정보를 전송 할 필요가 없다.
	▫️ 토큰이 만료되기 전까지는 한 번의 인증만 수행하면 된다.
    
- 권한 부여에 용이하다.

- 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이하다. 
	▫️ Github, Google 등 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능하다.

단점

- 유효기간이 없다.
	토큰 만료 시간을 별도로 지정해주지않으면 유효기간이 없으므로 사라지지 않아 위험 할 수 있다.
    
- 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.
	토큰에 저장하는 정보의 양이 많아질 수록 토큰의 길이는 길어진다.
    그러므로 request 를 전송할 때마다 길이가 긴 토큰을 전송하면 네트워크에 부하를 줄 수 있다.
    
- Payload 는 디코딩이 용이하다.
	토큰을 탈취하여 Payload를 디코딩하면 토큰 생성 시 저장한 데이터를 확인할 수 있다.
    그러므로 민감한 정보는 포함하지 않는 것이 좋다.

생성

1. Plain Text 형태의 Secret Key의 byte[] 를 Base64 형식의 문자열로 인코딩해준다.

jjwt가 버전업 되면서 Plain Text 자체를 Secret Key로 사용하는 것은 
암호학(cryptographic)적인 작업에 사용되는 Key가 항상 바이너리(byte array)라는 사실과 맞지 않는 것을 감안하여 
Plain Text 자체를 Secret Key로 사용하는 것을 권장하지 않고 있다.

Plain Text 란 암호화 되지 않는 문자열을 의미.

2. JWT 를 최초로 발급해주기 위한 생성 메서드. (인증된 사용자에게)
   2-1 Base64형식 Secret Key 문자열을 이용해 Key 객체를 얻는다.
   2-2 JWT 에 포함시킬 Custiom Claims 에는 추로 인증된 사용자와 관련된 정보를 추가한다.
   2-3 JWT 제목을 추가한다.
   2-5 JWT 만료일자 지정.
   2-6 서명을 위한 키 설정
   2-7 JWT 생성 하고 직렬화.

3. Access Token 을 재 생성해주는 메서드

4. JWT 의 서명에 사용할 Secret Key 를 생성해준다.

검증

JWT의 Signature 를 검증함으로써 JWT 의 위/변조 여부를 확인 할 수 있다.

jjwt 에서는 JWT 를 생성할 때 서명에 사용된 Secret Key 를 이용해 내부적으로 Signature 를 검증한 후, 검증에 성공하면 JWT 를 파싱해서 Claims 를 얻을 수 있다.

setSigningKey() 메서드로 서명에 사용된 secret key 를 설정한다.
parseClaimsJws() JWT 를 파싱해서 Claims 를 얻는다.

⚠️ 파라미터로 사용한 jws 는 signature 가 포함된 JWT이다.