네부캠 그룹프로젝트 - 2. 인증 로직에 대한 고찰

• Oauth로 얻은 Github token을 그냥 인증 유지에 사용할 지

• OpenID Connect(OIDC)를 인증에 사용할 지

• 왜 세션이 아닌 JWT를 선택했는지Refresh Token을 사용할 지

• JWT를 통한 인증 시, 어디까지 보안과 타협할 지Access Token과 Refresh Token을 어디에 저장할 지

1️⃣ Oauth로 얻은 토큰을 인증에 사용하면 안될까?

• 대부분의 기능이 Github에 종속적인 간단한 서비스이다.

• Github token에 repo에 대한 read scope만 명시하기도 하고, Github에서 해당 토큰을 사용자가 직접 무효화할 수도 있기 때문에 탈취 시 보안상 문제가 크지 않다.

• Oauth의 주는 토큰은 클라이언트측 앱을 위한 토큰이 아니다. 즉 인증(Authentication)이 아닌 Github측 자원에 대한 인가(Authorization)에 대한 토큰이다.

• 물론 OpenID Connect같은 인증 프로토콜을 사용하면 인증까지 위임할 수 있다. 하지만 추후 커뮤니티 기능이나 이력서 기능까지 확장성을 고려할 때 사용자에 대한 추가적인 정보가 요구될 수 있으므로 백엔드만의 인증 체계를 사용하는 편이 더 좋아보였다.

• 또한 OpenID Connect를 사용할 때 공급자가 여럿이면 편하겠지만, 서비스 특성상 Github만을 대상으로 하므로 괜히 복잡성만 커진다고 판단했다.

2️⃣ JWT 기반 인증의 장점

• 별도의 인증을 위한 저장소가 필요하지 않다.

• 여러 플랫폼(웹, 모바일 등)의 호환성을 크게 고려하지 않아도 된다.

• 여러 서버들이 클러스터링된 환경에서 처리가 더 편하다.

Refresh token을 저장해야 하는 거면, 별도의 저장소가 필요하니까 JWT의 장점이 사라지지 않는가?

• I/O 작업이 월등하게 줄어든다. 세션 방식은 요청마다 메모리 혹은 디스크에 접근하여 해당 세션이 존재하는 지 확인하는 과정이 필요하다.

• 하지만 위의 JWT 방식은 Access Token을 단순히 디코딩 하면 된다. JWT는 base64로 인코딩되므로 이를 디코딩하는 비용이 I/O 작업에 비해 훨씬 싸다.

• 그리고 Access Token이 만료된 경우에만 Refresh Token을 통한 I/O가 발생한다.

3️⃣ JWT는 만능이 아니다. 성능과 보안의 Trade Off

Access Token이 탈취당했을 때, 만료 기간이 남아있는 경우

• 만약 리소스 서버와 인증 서버가 분리된 경우, 매번 인증 서버에 검증 여부를 물어봐야 하고, 이는 곧 인증 서버의 병목 지점이 될 것이다.

• 인증 서버가 분리되지 않았다고 하더라도, 서버측 저장소가 필요하고 결국 latency에 악영향을 줄 수 밖에 없다.

Refresh Token이 탈취당하는 경우

4️⃣ Devrank가 선택한 인증 구조

• Access Token 무효화는 지원하지 않는다. 위에서 적은 것처럼 포기해야 하는 JWT만의 장점이 너무 크기 때문이다. 또한 서비스의 특성상 Access Token으로 할 수 있는 기능이 모두 Read-Only한 기능들이고, 여기에 민감한 정보는 포함되지 않는다.

• Refresh Token은 REDIS에 저장하여 관리한다. 만료 기간이 긴 특성상 Refresh Token에 대한 무효화는 필요하기 때문이다.

• RTR(Refresh Token Rotation)방식을 사용한다.
• Refresh Token을 통해 새로운 Access Token을 발급하면, Refresh Token도 새롭게 발급하는 방식이다.
• Refresh Token을 1회 사용하고 버리게 되므로, 성능에 크게 영향을 안미치면서도 보안적인 이점을 더 챙길 수 있다고 판단했다.
• 그렇지만 여전히 사용되지 않은 Refresh Token이 탈취당하는 경우에 보안상 허점은 어쩔 수 없다. 따라서 이미 사용된 Refresh Token으로 요청이 들어오면 해당 유저에 대한 모든 토큰을 무효화시키는 방향으로 로직을 구현하였다.

5️⃣ 클라이언트 측에서 보는 인증 구조

• React 클라이언트에서 CSR을 통한 라우팅에서는 Access Token을 상태로 관리하면서 인증을 유지하면 된다.

• 새로고침으로 인해 상태가 날라가는 경우, 페이지 로드 시 /refresh같은 서버측 API를 호출하여 자동적으로 쿠키에 있는 Refresh Token을 통해 새로운 Access Token을 받아 인증 유지가 가능해진다.
• 우리는 Next.js를 사용하므로 SSR시에 refresh를 위한 API를 호출하면 된다.

Cookie에 Refresh Token을 저장하는 보안적인 이유

• Local Storage, Session Storage 등 여러 선택지가 있지만 이들은 결국 Javascript 코드로 접근이 가능하므로 XSS 공격에 노출될 수 밖에 없다.

• 하지만 Cookie는 HttpOnly 옵션을 설정하여 XSS 공격 방지가 가능하다. 또한 Secure옵션도 설정 가능하다.

• 추후에 SameSite까지 설정하여 CSRF 공격에 대해 보안적으로 이점을 더 가져갈 수 있다.
• 물론 CSRF 공격을 막기 위해 서버측이 CORS를 제대로 설정하고, referer를 검사하는 등의 설정은 필요하다.

Access Token 만료 시, refresh 요청 자동화

참고