JWT, Access, Refresh Token

https://tansfil.tistory.com/58?category=475681 

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없습니다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 됩니다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능합니다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어갈 수 있습니다. 

-> 해결책

기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급합니다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있습니다. 이는 다음 포스팅에 나올 Oauth2에 더 자세히 다루도록 하겠습니다.

2. Payload 정보가 제한적입니다. 위에서 언급했다시피 Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다. (세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관됩니다) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없습니다.

3. JWT의 길이입니다. 세션/쿠키 방식에 비해 JWT의 길이는 깁니다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 됩니다.

 

https://tansfil.tistory.com/59?category=475681 

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

Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다(여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미입니다.) 

 

사용 예를 간단히 들어보겠습니다. Refresh Token의 유효기간은 2주, Access Token의 유효기간은 1시간이라 하겠습니다. 사용자는 API 요청을 신나게 하다가 1시간이 지나게 되면, 가지고 있는 Access Token은 만료됩니다. 그러면 Refresh Token의 유효기간 전까지는 Access Token을 새롭게 발급받을 수 있습니다. 

 

** Access Token은 탈취당하면 정보가 유출되는건 동일합니다. 다만 짧은 유효기간 안에만 사용이 가능하기에 더 안전하다는 의미입니다. 

 

** Refresh Token의 유효기간이 만료됐다면, 사용자는 새로 로그인해야 합니다. Refresh Token도 탈취될 가능성이 있기 때문에 적절한 유효기간 설정이 필요해보입니다(보통 2주로 많이 잡더군요)

 

https://tansfil.tistory.com/60?category=475681 

쉽게 알아보는 서버 인증 3편(SNS 로그인, OAuth 2.0)

Oauth 는 외부서비스의 인증 및 권한부여를 관리하는 범용적인 프로토콜입니다. 

 

* 권한 : OAuth는 인증뿐만 아니라 권한도 관리합니다. 사용자의 권한에 따라 접근할 수 있는 데이터가 다르도록 설정이 가능합니다. 

 

* 프로토콜 : 특정한 프로그램을 지칭하는게 아니라 일종의 규격입니다. Facebook, Google, Naver 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행관리 해줍니다

 

* 외부서비스 : 우리가 만들고 있는 서비스를 이야기합니다. 외부 서비스를 위한 서비스인 OAuth는 우리 서비스의 인증 및 권한부여를 관리를 대행해줍니다.

 

한 가지 명심해야할 점은, 우리가 배웠던 (사용자 <-> 어플리케이션 서버) 인증 절차였던 세션/쿠키, 토큰 기반 인증 방식을 완전히 대체하는게 아니라는 점입니다. 즉 SNS 로그인 기능을 넣더라도 결국은 세션/쿠키 방식이나 토큰을 활용해 인증을 거쳐야 합니다. 이 부분은 아래에서 더 상세하게 다루겠습니다.

 

 

https://velog.io/@park2348190/JWT%EC%97%90%EC%84%9C-Refresh-Token%EC%9D%80-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%9C%EA%B0%80

JWT에서 Refresh Token은 왜 필요한가?

만약 공격자가 Refresh Token을 탈취해서 정상적인 사용자가 Access Token을 다시 발급받기 전에 자기가 먼저 Access Token을 생성한다면 어떻게 될까? 이 경우에도 Access Token의 충돌이 일어나기 때문에 서버측에서는 두 토큰을 모두 폐기(만료 대신 폐기가 어울리는 용어인 것 같다)해야 할 것이다. 그래서 ietf 문서에서는 아예 Refresh Token도 Access Token과 같은 유효 기간을 가지도록 하여 사용자가 한 번 Refresh Token으로 Access Token을 발급받았으면 Refresh Token도 다시 발급받도록 하는 것을 권장하고 있다.

 

 

https://daco2020.tistory.com/315

Refrsh token을 구현하며 느낀 점

하지만 이 로직에는 몇 가지 문제점이 있었습니다.

우선 기본적으로 jwt로 구현한 토큰 로그인 방식은 stateless를 전제로 합니다.

이것이 무슨 말이냐면 jwt의 원래 목적은 상태(데이터)를 서버에 저장하지 않고 토큰 자체만으로 상태를 관리하는 용도라는 것입니다.

 

토큰 안에는 정보를 담을 수 있으므로 데이터베이스에 굳이 저장을 하지 않아도 됩니다.

그럼에도 리프레시 토큰을 데이터베이스에 저장한다는 것은 서버가 상태를 관리한다는 뜻이고

이는 상태 관리의 효율을 떠나 원래의 jwt 목적에 반한다는 것입니다.

 

게다가 액세스 토큰의 재발급만이 목적이고 데이터베이스에 저장을 할 것이라면 굳이 jwt 같은 토큰 방식을 사용할 이유가 없습니다.

 

또 다른 문제점은 로그인 상태를 여러 기기에서 유지할 수 없다는 점입니다.

유효한 리프레시 토큰이 한 개라면, 로그인 혹은 액세스 토큰 재발급 시에 새로운 리프레시 토큰으로 대체되기 때문에 어느 한 기기에서 로그인을 하거나 액세스 토큰을 재발급받는다면 다른 기기에서는 더 이상 리프레시 토큰을 사용할 수 없게 됩니다.

이는 보안의 측면에서 장점이 될 수 있지만 요즘 같이 여러기기를 동시에 사용하는 환경에서는 큰 불편을 가져다줄 수 있습니다.

 

https://ooeunz.tistory.com/74

[Tech] JWT(Json Wet Token)이란?

세션과 비교 하였을 때 JWT

JWT는 세션과 비교하였을 때 무상태(stateless)와 확장성(scalability)의 이점이 있다. 토큰은 클라이언트에서 저장하기 때문에 서버측에서는 stateless하며, 요청이 왔을 때 서명이 옳바른지만 확인하면 되므로 비저장의 이점을 지닌다. 또한 msa와 같은 서버가 여러대로 분리되어 사용되고 있다면 어떤 유저가 로그인 햇을 때 그 유저가 처음 로그인했었던 서버에만 요청을 보내야 하기 때문에 확장성에 제약이 있지만 토큰방식을 사용한다면 어떤 서버로 요청이 오더라도 관계없이 인증할 수 있다. 또한 보안적으로도 기존의 세션 방식의 HTTP 요청을 해커가 가로챌 경우 그 안의 쿠키를 이용해 악용될 수 있는 보안적 약점을 보완했다.