65일차: 자격 증명 / JWT 인증

❯ 자격 증명

HTTP 프로토콜은 요청 - 응답이 종료되면 상태를 저장하지 않고 연결이 끊어지게 된다. (무상태성, 비연결성)

로그인 상태가 유지되지 않는다면 해당 계정으로 추가적인 요청을 할 때마다 로그인 정보를 다시 전송해야 할 것이다.

이런 부분을 개선하기 위해 '자격 증명'을 통해 인증된 사용자 정보를 저장해야 한다.

자격 증명 방식은 크게 두 가지로 나누어 설명할 수 있다.

• 세션 기반 자격 증명 방식: 인증된 사용자 정보를 세션 형태로 세션 저장소에 저장하는 방식. 인증 정보를 서버 쪽 세션 저장소에서 관리한다. SSR 방식에 적합한 형태이다.
• 토큰 기반 자격 증명 방식: 자격 증명 정보(Credential)를 통해 토큰(Token)을 부여받는 방식. 한번 사용자 자격을 인증받은 후에는 인증된 토큰을 Http request 헤더에 포함해서 인증된 사용자임을 증명하는 수단으로 쓴다. CSR 방식에 적합한 형태이다.

❯ JWT(JSON Web Token)

JSON 포맷의 토큰 정보를 인코딩한 후 인코딩된 토큰 정보를 Secret Key로 서명하고 Web Token으로 사용하는 것을 말한다.

크게 두 가지 토큰으로 구분된다.

• Access Token: 보호된 정보에 접근할 수 있는 권한을 부여하는 데 사용되는 토큰. 실제 권한 부여에 사용되며 보안을 위해 비교적 짧은 유효기간을 갖는다.
• Refresh Token: Access Token의 유효기간이 만료되면 새로운 Access Token을 발급받기 위해 사용되는 토큰. 비교적 긴 유효기간을 갖는다. 보안이 중요한 경우 사용하지 않는 경우도 많다.

JWT의 구조

JWT는 . 으로 나누어진 세 가지 부분으로 구분된다.

Header, Payload에 포함된 JSON 형태의 데이터는 base64로 인코딩 된다. 이후 암호화된다.

 

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

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

2. Payload: 서버에서 사용할 수 있는 사용자 정보(이름, 권한 등)가 담긴다. 복호화가 가능하므로 민감한 정보는 담지 않는 것이 좋다.

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

3. Signiture: 지정된 비밀키와 Header에서 지정한 알고리즘을 사용해 Header와 Payload의 단방향 암호화를 수행한다.

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

토큰 기반 인증 절차

 

⑤ 에서 헤더에 토큰을 포함할 때

Bearer Authentication을 사용한다. 

 

 

 

 

 

 

 

 JWT의 장단점

장  점	- 클라이언트가 요청 전송시마다 자격 증명 정보를 전달할필요 없음 (토큰을 사용함) - 인증을 담당하는 시스템을 다른 플랫폼으로 분리하기 용이함 - 권한 부여가 용이함
단  점	- JWT는 디코딩이 용이함 (Base64를 통해 인코딩하기때문) - 토큰이 길어지면 네트워크에 부하를 줄 수 있음 - 토큰은 자동으로 삭제되지 않음(만료 시간을 지정해주어야함)

---

오늘은 JWT에 대한 기본적인 이론에 대해 학습했다.

개념에 대해서는 어느 정도 이해가 된 것 같다. 지난번 배운 Spring Security에 대해 다시 한번 복습해 보고

내일 Spring Security에서의 JWT인증도 잘 따라갈 수 있도록 해야겠다.