스프링-리액트 OAuth2 JWT

Question

안녕하세요! 백엔드 공부하고 있는 학생입니다!!토이프로젝트로 스프링-리액트를 이용한 게시판 웹 제작 중입니다.네이버 OAuth2 JWT를 이용해 로그인을 구현하고 있는데, 모든 책임(?)을 백엔드(스프링)에서 맡아서 로그인을 구현 중입니다예를 들어 프론트에서 하이퍼링크를 통해 로그인 요청을 보내면 백엔드에서 OAuth2 코드발급 및 토큰생성까지 다하고 프론트로Accecc토큰, Refresh토큰을 넘겨줄 계획입니다. Access토큰은 헤더로 바로 보내 주려하니 네이버 보안정책상 CORS가 발생하여 URI에 Access를 담아 프론트로 보냈고, Refresh토큰은 쿠키로 담아 전송했습니다.문제는 리액트로 보낸 access(URI), refresh(쿠키)을 권한이 필요한 페이지 접속을 위해 백엔드로 전달하려 하니 access는 헤더로 잘 넘어오는데 refresh가 쿠키로 넘어오지 않는 문제가 발생하여 조언을 구하고자 합니다!설명을 어떻게 해야 전달이 잘 될지 몰라서 글이 어수선합니다.. 죄송합니다ㅠㅠ

kenu,전독시 · Answer

쿠키는 1차 도메인을 맞춰야 간신히 전달됩니다.

kenu,전독시 · Answer

HTML 파일 (index.html) Cookie Sharing Example

Cookie Sharing between okdevtv.com and mp4.okdevtv.com

JavaScript 파일 (script.js)document.getElementById('setCookie').addEventListener('click', function() { // Set a cookie on okdevtv.com domain document.cookie = "session=123456; domain=.okdevtv.com; path=/"; // Redirect to mp4.okdevtv.com to access the shared cookie window.location.href = "https://mp4.okdevtv.com"; }); 이 예제에서는 다음과 같이 작동합니다:사용자가 "Set Cookie" 버튼을 클릭하면, JavaScript 코드가 실행됩니다.JavaScript 코드는 document.cookie를 사용하여 session이라는 이름의 쿠키를 설정합니다. 이 쿠키는 .okdevtv.com 도메인에 대해 유효하며, 모든 경로(/)에서 접근 가능합니다.이후, 페이지는 자동으로 https://mp4.okdevtv.com로 리다이렉트됩니다. 여기서 mp4.okdevtv.com도 okdevtv.com 도메인의 하위 도메인입니다. 따라서, 동일한 도메인 내에서 설정된 쿠키는 다른 하위 도메인에서도 접근 가능합니다.이 방법은 여러 하위 도메인 간에 사용자 세션 정보를 공유할 때 유용하게 사용될 수 있습니다. 하지만, 보안상의 이유로 민감한 정보를 쿠키에 저장하지 않도록 주의해야 합니다.from: https://www.phind.com/search?cache=rwfsaonymdfqn6xyhi13f9ai

charlatan · Answer

딴지를 또 걸게 되는데 양해바랍니다. &#x1f61d;질문 내용에 네이버 이야기가 나오는 것으로 봐서는 네이버에서 발급한 액세스 토큰과 리프레시토큰을 브라우저에 보내려고 하는 것 같네요?제 생각에는 OAuth2&#43;JWT 와 OAuth2&#43;로그인(인증) 이 두 가지를 하나로 생각하다보니 마치 네이버의 액세스 토큰과 리프레시 토큰을 브라우저에 심어야 한다는 이상한 논리가 나오는 것 같습니다. 이 두가지는 차이가 있습니다. 그리고 대부분 원하는 것은 후자 그러니까 OAuth2&#43;로그인(인증)입니다. 질문도 그 의도라고 보입니다.스프링 시큐리티가 이 두 가지를 잘 구분해 놓았는데 바로 OAuth2Login, OAuth2Client입니다(그리고 OAuth2 Resource Server). OAuth2&#43;JWT는 벨둥 사이트에 있는 것을 참조하면 됩니다.하지만 OAuth2&#43;로그인(인증)에서는 액세스 토큰을 인증용으로 생각할 수 있을지는 몰라도 리프레시 토큰은 그 성격이 다릅니다. 리프레시 토큰은 옵션으로, 네이버에서는 같이 발급해주지만 구글은(아마 깃허브도 마찬가지) 같이 주지 않습니다. OAuth2&#43;로그인(인증)에서 리프레시 토큰은 클라이언트(사용자 브라우저가 아니라 제3자 애플리케이션, 즉 내가 만드는 백엔드)가 사용자 로그아웃 후에도 백엔드에서 그 사용자의 정보를 네이버에서 조회하려는 목적입니다. 제3자에게 개인정보 제공 동의와 유사한 개념입니다.구글의 OAuth2 로그인에서 이러한 설명을 잘 해놓아서 옯겨봅니다.Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.https://developers.google.com/identity/protocols/oauth2/web-server#offline리프레시 토큰은 회수하지 않는한 매우 오랜 기간 쓸 수 있습니다. 그것을 브라우저에 보관한다는 것은 위험한 일이고 그래서 많은 사람들이 HttpOnly 쿠키에 저장하려고 하는데 앞서 말한 것처럼 리프레시 토큰의 용도가 그것과는 거리가 있으므로 그럴 이유가 없다는 말입니다. 네이버 가이드에도 백엔드 DB에 저장을 예로 들고 있습니다. 어떻게 보면 네이버 사용자 개인 정보에 접근할 수 있는 중요한 토큰을 자동 로그인 같은 기능으로 활용한다는 것 자체가 이상합니다.만약에 액세스/리프레시 토큰으로 직접 리액트 프론트 앱에서 사용자 정보를 네이버로부터 가져와서 보여주려는 목적이라면 그것 역시 비효율적이고 더구나 CORS 문제도 있습니다. 어디까지나 내가 만든 프론트는 내가 만든 백엔드로 API를 호출해야 CORS나 데이터 일관성 문제를 줄일 수 있습니다.그리고 프론트에서 백엔드가 심은 쿠키를 못읽는 것은(두 서버가 다를때) 쿠키의 특성상 당연합니다. 프론트를 백엔드 서버에 정적 리소스로 같이 넣으면 이런 복잡한 문제가 많이 해결되겠지만 반드시 그렇게 할 필요는 없겠죠. 프론트에서 axios 같은 것으로 API를 호출할 때 withCredentials이라는 옵션이 있습니다. 이 옵션은 XMLHttpRequest의 표준입니다. 관련 자료를 찾아보면 프론트와 백엔드의 설정을 통해 쿠키의 CORS를 해결할 수 있습니다. 백엔드로 스프링 시큐리티를 쓴다면 시큐리티의 CorsConfigurationSource 빈을 설정하면 해결할 수 있습니다. 관련 자료를 잘 찾아보시면 좋겠네요.

ccat · Answer

refreshToken값을 보낼 때 credentials: 'include' 해서 보내셨나요

밥잘먹는사람 · Answer

스프링 시큐리티 CORS 설정할 때setAllowCredentials(true); 로 설정하셨나용?

스프링-리액트 OAuth2 JWT

5개의 답변

기술 목록