[Web] 인증과 인가 - JWT Auth

앞 포스팅에서 세션 방식의 인증과, 성능 개선을 위한 방법들에 대해서 다루어 보았었는데

이번에는 언급했던 토큰 인증 방식에 대해서 알아보려고 한다.

 

---

토큰 인증

• 세션 인증 방식과 달리 인증이 완료되었을 시 인증 정보를 서버에 저장하는 것이 아니라 클라이언트에 저장하는 것이다.
• 인증을 완료하면 서버는 인증완료 의미의 토큰을 클라이언트에게 부여한다
• 클라이언트는 API 요청 시, 토큰을 HTTP 헤더에 붙여서 보내게 되며 서버는 토큰을 바탕으로 인가처리를 한다.
• 토큰은 암호화되어 클라이언트에 저장된다.
• 웹 이외에 쿠키와 세션을 이용할 수 없는 Application에서의 인증을 구현하기에도 유리하다. 
• 토큰은 일반적으로 유효 시간(Expired Time)을 설정하여 발급하여 기간이 지날 시 사용할 수 없게 된다.

 

 

 

---

JWT 토큰

• Json Web Token, 웹에서 토큰 인증 방식으로 많이 사용되는 토큰의 종류이다.
• JSON으로 만들어진 인증 관련 정보를 인코딩한 토큰이다.
• 토큰에 대한 기본정보, 인증에 대한 서버측에 전달할 정보, 검증되었음을 증명하는 Signature를 포함한다.

 

 

---

JWT 토큰의 구조

 

JWT 토큰은 base64로 인코딩되어 아래와 같은 문자열 형식을 사용한다.

(Header)xxxxxxxxx.(Payload)xxxxxxxxx.(Signature)xxxxxxxxx

 

Header

• typ : 토큰의 타입, JWT
• alg : 인코딩에 사용됨 해싱 알고리즘 종류

 

 Payload

토큰에 담을 정보가 들어있다. JSON 쌍으로 구성됨

 

• 등록된 클레임 : 토큰의 기본 정보를 담기 위한 이름이 정해져 있는 정보이다. 
  • iss : 토큰 발급자 
  • sub : 토큰 제목
  • aud : 토큰 대상자
  • exp : 토큰의 만료 시간, 해당 시간이 끝난 이후에는 사용할 수 없음
  • iat : 토큰이 발급된 시간
  • nbf : 토큰의 활성화 시간, 해당 시간이 지나기 전에는 사용할 수 없음

 

• 공개 클레임 : 원하는 대로 정의한 클레임. 충돌이 방지된 이름을 가지고 있어야 함
• 비공개 클레임 : 서비스에서 공유하기 위한 정보를 담은 클레임. 이름이 중복되어 충돌될 수 있음. 인증에서의 사용자 ID 등이 이곳에 담긴다. 

 

Signature

• 유효성을 검증하기 위한 부분. 
• 헤더의 인코딩값과 페이로드의 인코딩값을 합친 후 토큰을 생성할 때 사용된 Secret Key를 통해 암호화하여 생성한다.

 

---

JWT Token 인증 플로우

 

ID와 비밀번호를 이용한 인증과 인가 플로우에 대해서 살펴보자.

 

	클라이언트	서버
인증
1	로그인 요청
2		데이터베이스에서 ID와 비밀번호 대조 후 일치여부 확인
3		일치 시 암호화된 토큰 생성
4		응답으로 토큰을 반환
5	클라이언트는 토큰을 저장
인가
1	API 요청 시 헤 토큰을 포함시켜 요청
2		토큰을 복호화하여 유효성 검증
3		검증 완료되었다면 API 로직 처리 후 응답
4	응답을 받음

 

 

인증

1. 클라이언트는 ID와 비밀번호를 포함하여 서버에 로그인 요청을 보낸다.

2. 서버는 ID와 비밀번호를 데이터베이스의 회원 정보와 대조 후 인증 여부를 판단한다.

3. 일치 시 Secret Key를 이용하여 암호화된 토큰을 생성한다. 토큰에는 인증정보, 서명 문자열, 사용자의 일부 정보(비밀번호와 같은 민감정보는 포함시키지 않는 편)를 포함한다. 해당 토큰에는 만료 시간(ExpiredIn)을 설정한다.

4. 클라이언트는 Cookie나 Stroage, Application 내부 등에 반환받은 토큰을 저장해둔다.

 

 

인가

1. 클라이언트는 API 요청 시 HTTP 헤더에 인증과정을 거친 후 발급받은 토큰을 포함시켜 요청한다.

2. 서버는 헤더에 포함된 토큰을 Secret Key를 통해 Signature 부분의 유효성을 검증한다.

3. 유효한 토큰이라면 인가에 성공했으며, API 요청 처리 및 응답을 한다.

4. 클라이언트는 API의 응답을 받는다.

 

 

 

---

Access Token과 Refresh Token

 

JWT 토큰의 단점과 보완

• Payload 부분은 단순히 base64형식으로 인코딩했한 수준이기 때문에 안의 데이터를 볼 수 있다. 따라서 민감한 데이터를 넣지 않는다.
• 이미 발급된 토큰에 대해서는 사용자의 인증과 인가 처리를 무효화하기 어렵다. 따라서 토큰이 탈취당하여 사용될 수 있다.
• 위의 문제를 극복하기 위해서 토큰 만료 시간을 짧게 주어 탈취당하여 사용되기 이전에 무효화시키는 방법을 사용한다.
• 그렇지만 토큰 만료 시간을 짧게 준다면 매번 다시 인증 과정을 거쳐야 하는 문제가 있다.
• 이를 위해 도입된 개념이 Access Token과 Refresh Token의 개념이다.

 

JWT Access /Refresh Token 인증 플로우

 

토큰 만료 시간을 짧게 주게 되면 다시 인증 과정을 거쳐 재발급을 받아야 한다.

그래서 다시 로그인같은 인증 과정을 거치는 것이 아니라, Refresh Token을 통해서 인증 과정을 대신하려고 한다.

평상시 API 인가에 사용되는 토큰이 Access Token이라면,

Refresh Token은 Access Token이 만료되었을 헤더에 포함시켜서 Access Token 재발급 요청을 하는 데에 사용된다.

보통 Access Token은 시간을 2~5분 내외같이 짧게 주는 반면 Refresh Token은 2주 정도로 길게 주는 편이다.

 

	클라이언트	서버
인증
1	로그인 요청
2		데이터베이스에서 ID와 비밀번호 대조 후 일치여부 확인
3		일치 시 암호화된 토큰 생성
4		응답으로 Access 토큰 / Refresh 토큰을 반환
5	클라이언트는 토큰을 저장
인가
1	API 요청 시 헤더에 Access Token을 포함시켜 요청
2		토큰 유효성 검증
3		유효성 확인 중 Access Token 만료가 되지 않음
4	응답을 받음	검증 완료되었다면 API 로직 처리 후 응답
재발급
1	API 요청 시 헤더에 Access Token을 포함시켜 요청
2		토큰 유효성 검증
3		유효성 확인 중 Access Token 만료됨
4		응답으로 Access Token 만료가 되었음을 보냄
5	Refresh Token을 헤더에 포함시켜 Access Token 재발급 요청
6		Refresh Token의 유효성 검증
7		새로운 Access Token을 응답으로 반환하여 발급
8	새로운 Access Token 저장

 

인증

• 앞의 인증 플로우와 다른 점은 인증 완료 시 Access Token과 함께 Refresh Token을 발급한다.

 

인가와 토큰 재발급

• 인가 중 Access Token이 만료되었을 때 클라이언트에 만료되었음을 응답으로 보낸다.
• 클라이언트는 만료되었음을 확인하고 Refresh Token을 헤더에 실어서 Access Token의 재발급을 요청한다.
• 서버는 마찬가지로 Refresh Token의 유효성을 검증한 후, Access Token을 재발급한다.
• 재발급된 Access Token으로 API 요청을 한다.

 

 

 

 

보통 Refresh Token은 Access Token보다 출처 확인 등의 엄격한 검증 과정을 거친다.

Refresh Token을 사용하면 Access Token만 사용할 때 보다 안전하다. 그렇지만 HTTP 요청이 많아진다는 단점이 있다.

서비스에 따라서 어떤 방식을 사용할 지 장단점을 비교해서 사용해보도록 하자.

 

 

 

---

 

 

 

Reference

https://doqtqu.tistory.com/275

[JWT] JWT(JSON Web Token) 설명 및 구조

https://tansfil.tistory.com/59

쉽게 알아보는 서버 인증 2편(Access Token + Refresh Token)