Dva: oauth2 인증 샘플

oauth2 인증은 url 리다이렉션으로 하는거 아닌가요? 쿠키로 판단해서 로그인하면 괜찮습니다.

OAuht2 중 일부는 url이 아닌 순수한 RESTFul 형식인 access_token을 통해 수행됩니다.

dva 및 Spring Boot Oauth2 통합의 예가 있으면 더 좋을 것입니다. D

@soulmachine 저는 이것을 사용하고 있는데 시간이

@WhatAKitty 는 access_token을 전달합니다. access_token은 어디에 저장됩니까? local/seesionStorage에 저장하면 XSS 보안 위험이 있습니다.

@u0x01 은 .Access_token 은 시간 제한이 있습니다.시간 초과 후에는 다시 로그인할 수 없으며, refresh_token 권한이 없습니다. 더군다나 다른 방법은 없고 다른 관련 정보를 조회하여 모두 localstorage에 저장합니다.

@WhatAKitty Now 해커는 자동화된 도구를 사용하거나 작성하여 공격합니다. access_token의 유효 기간 2시간이면 많은 일을 할 수 있습니다. "리스크가 크지 않다"는 결론은 어떻게
둘째, refresh_token이 localstorage에 배치되지 않은데 어디에 두나요?
access_token은 APP에 더 적합합니다. 순수 JS 측에서는 access_token 체계를 사용하지 않아야 합니다. 여전히 교차 사이트 공격의 위험이 있습니다.
현재 가장 안전한 솔루션은 set-cookie에 http-only를 추가하는 것입니다.
로그인 확인 시 서버에 쿠키를 가져와 시전 상태를 가져오며 실패할 경우 로그인 페이지로 바로 이동합니다.
안전은 또한 생산성이며 Taishan보다 더 중요하므로 여기에서 게으르지 않을 수 있습니다.

@u0x01 refresh_token, js 클라이언트에는 주지 않겠습니다. 따라서 만료되면 다시 인증을 받아야 합니다. 우리의 응용 프로그램이 다음과 같기 때문에 이전에 명확히하지 않았을 수 있습니다. 당신은 나타나지 않을 것입니다.. 다양한 위험이 있습니다.
가장 안전한 해결방법은 쿠키를 사용하는 것도 고려했는데 하나: LOGIN PASSWORD로 로그인한 후 access_token을 반환할 수 없기 때문에 서버를 OAUTH2와 LOGIN PASSWORD와 동시에 호환되도록 하지 않았습니다. , 다른 방법이 있을 수 있지만 찾지 못했습니다. 둘째: 프로젝트의 시간 요구 사항으로 인해 이 옵션은 절충안으로만 선택할 수 있습니다. 따라서 이 계획은 다소 부적절해 보이지만 사실 보안상의 문제는 없을 것입니다.

@WhatAKitty는 SSL이 "XSS/CSRF의 공격으로부터 웹사이트를 보호할 수 있다"고 들어본 적이 없으며 둘 사이에는 직접적인 관계가 없습니다.
웹 사이트 시스템에 XSS/CSRF 취약점이 100% 없다고 보장할 수 있다면 이를 localStorage에 저장하고 JS가 자격 증명에 직접 액세스하도록 할 수 있습니다. (하지만 시스템에 보안 허점이 없다고 감히 투표하는 회사는 본 적이 없습니다.)

그리고 사용자가 인증해야 하는 특정 리소스에 액세스한다는 것이 무엇을 의미하는지 이해하지 못합니다. OAuth2 사양에서 access_token을 얻는 것은 사용자(또는 공급자)가 이 권한을 승인했음을 의미합니다.

또한 다음을 언급했습니다.
因为没法在使用 LOGIN PASSWORD 登录后给我返回一个access_token
OAUth2 사양에 대한 오해와 잘못된 사용법입니다.

LOGIN PASSWORD 방법은 본질적으로 UA가 OAUth2 공급자에게 직접 인증을 요청하는 프로세스입니다(RFC6749 참조) . 이때, authorization_code를 획득해야 하며, UA가 authorization_code를 획득한 후 OAUth2 Provider의 유효성을 확인하기 위해 Client에게 이를 전송하게 되며, 검증이 통과되면 Client는 OAUth2 Provider로부터 access_token을 받게 됩니다. 이때 Client는 access_token을 이용하여 자원에 접근할 수 있다. 그런 다음 클라이언트는 UA에 SessionID를 발급합니다.
(여기서 클라이언트는 최종 사용자가 아닌 비즈니스 당사자의 서버 또는 APP를 말하며 최종 사용자는 리소스 소유자, UA는 브라우저)

대체로 SessionID를 사용하여 사용자를 인증해야 합니다. SessionID를 사용하지 않더라도 access_token을 http 전용 쿠키에 넣어야 합니다.

1. Don't use local storage for session identifiers. Stick with cookies and use the HTTPOnly and Secure flags.
2. If cookies won't work for some reason, then use session storage which will be cleared when the user closes the browser window.
3. Be cautious with storing sensitive data in local storage. Just like any other client side storage options this data can be viewed and modified by the user. 

실제로 access_token을 클라이언트에 노출하려는 경우 절충 방법은 다음과 같습니다.

// GET /seesion
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" {
        ctx.JSON(200, {"signed": true, "access_token": access_token})
    } else {
        ctx.Redirect("//yoursite.com/login")
    }

그러나 나는 여전히 그것을 쿠키에만 넣는 것이 좋습니다.JS는 GET /seesion 메소드를 사용하여 로그인했는지 확인합니다.다른 리소스는 평소와 같이 액세스합니다.서버는 access_token이 만료되었음을 발견한 후 바로 로그인 페이지로 이동합니다. :

// GET /seesion
    access_token := ctx.Session().GetString("access_token")
    if signed != "" {
        ctx.JSON(200, {"signed": true})
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

// GET /posts/:postid
    access_token := ctx.Session().GetString("access_token")

    if access_token != "" && isValidAccessToken(access_token) {
        ctx.JSON(200, getPostWithAccessToken(access_token, postid))
    } else {
        ctx.Redirect("//yoursite.com/login"， "you need login first.")
    }

물론, 귀하의 웹사이트 시스템에 공격 가치가 없다고 생각한다면 저는 아무 말도 하지 않았습니다.

이런 종류의 "부적절해 보이지만 실제로는 안전상의 문제는 없을 것"이라고 생각하면서 앞으로 고용주에게 얼마나 많은 손실을 줄지 모릅니다.
기업 정보 보안 유출 목록
실시간으로 100만 고객 정보가 팔려나갔다 (이 회사의 정보보안 유출 문제는 아직까지 완전히 해결되지 않았고, 프로덕트 동호회 등 다수의 대형 전자상거래 업체에서 금지)

정보 보안은 갈 길이 멉니다.

@u0x01
아까 답변드린 내용을 말씀드리자면 불명확할 수 있습니다.. access_token을 획득하는 과정에서 client_id와 client_secret(필요하지 않을 수 있음) 뿐만 아니라 사용자 이름과 비밀번호도 필요합니다.

XSS/CSRF의 공격으로부터 웹사이트를 보호할 수 있습니다.

CSRF가 비활성화되었습니다. XSS의 경우 데이터베이스에 저장된 모든 콘텐츠가 자동으로 전송되고 불법적인 필드가 필터링됩니다. 누락이 있을 수 있지만 완전히 제거하는 것은 불가능합니다. 정보 보안이 절대적으로 안전한 것은 아닙니다. Microsoft와 Apple도 마찬가지입니다. 나는 당신을 믿지 않습니다. 시스템은 100% 안전을 달성할 수 있습니다.

SessionID를 사용하지 않더라도 http only 쿠키에 access_token을 넣어야 합니다.

Http만 절대적으로 안전한 것은 아닙니다.

OAUth2 사양에 대한 오해와 잘못된 사용법입니다.

잘못된 사용으로 간주되는지 모르겠지만 내 응용 프로그램에서 승인 페이지를 요청할 수 있습니다 사용자가 로그인한 후 승인 페이지를 얻은 다음 액세스에 동의합니까? 너무 많은 문제입니까? 현재로서는 자체 애플리케이션을 위해 이 작업을 수행하는 웹사이트는 없습니다.

또한 본인의 서버가 OAuth2 인증 서비스를 제공하기 때문에 이상적인 인증 방식이 말씀하신 것과 다를 수 있습니다. 따라서 내 브라우저 클라이언트의 경우 다음과 같다고 생각합니다. UA가 AS를 요청하고 AS가 인증되지 않은 것을 발견하고 LOGIN으로 점프한 다음 사용자가 로그인한 후 서버에 액세스할 수 있는 권한을 성공적으로 얻습니다(이는 access_token일 수도 있고) 리소스 서비스 액세스 권한을 직접 열 수 있음), 그러면 사용자는 js 측 리소스 서버에서 직접/간접적으로(access_token) 리소스를 요청할 수 있습니다.

즉, 제 이상적인 인증 방법은 자체 UA에 대한 것인데, 제 3자라면 말씀하신 Authorize_code를 사용하여 사용자가 접근할 수 있는 권한 페이지를 얻어야 할 수도 있다고 생각합니다.

위의 방법이 가장 이상적인 인증 방법이지만 안타깝게도 제 수준이 제한되어 있고 Spring의 OAuth2를 통해 원하는 효과를 얻을 수 없습니다.

나는 그것이 미래에 당신의 고용주에게 얼마나 많은 피해를 줄지 모릅니다.

우선 저희 프로젝트가 매우 시급하고 아키텍처가 최근에야 따라 잡았다는 점을 말씀드리고 싶습니다. 그러나 시간이 허락하지 않는 당신의 상사는 기술 보안을 재생하면서 클라이언트의 프로젝트를 드래그하도록 허용합니까? 현실은 종종 잔인합니다. 상사는 고객의 안전에 전혀 관심이 없을 수 있습니다. 그들은 이익에 더 관심이 있습니다. 내가 할 수 있는 유일한 일은 가능한 한 많은 안전을 보장하는 것뿐입니다.

@u0x01 사실 저도 제가 설계한 아키텍처를 보안 문제 없이 만들고 싶지만 현실은

1. 제 개인적인 기술 수준으로는 이 요구 사항을 충족할 수 없으며 기술 전문가가 아닙니다.
2. 나를 안내해줄 진정한 기술 전문가가 부족하고 누군가가 나를 안내해 준다면 나는 행복할 것 같다.

지금까지 내 모든 기술은 지도 없이 한 사람이 탐색했는데, 일부 부족한 솔루션은 사실 내 단점입니다.

@WhatAKitty
당신의 프로젝트는 바쁘고 상사는 신경 쓰지 않으니 지금 당신의 아이디어에 따라 하세요.

하지만 자신의 애플리케이션에서 권한 페이지를 요청할 수 있습니까?사용자가 로그인한 후 권한 페이지를 얻은 다음 액세스에 동의합니까? 너무 많은 문제입니까? 현재로서는 자체 애플리케이션을 위해 이 작업을 수행하는 웹사이트는 없습니다.

OAuth2의 관련 사양을 참조하십시오. OAuth2는 묵시적 권한의 개념을 가지고 있습니다.

즉, 제 이상적인 인증 방법은 자체 UA에 대한 것인데, 제 3자라면 말씀하신 Authorize_code를 사용하여 사용자가 접근할 수 있는 권한 페이지를 얻어야 할 수도 있다고 생각합니다.

OAuth2는 제3자 개념이 없는 것 같습니다.

게다가 CSRF 보호 기능이 비활성화된 상태에서 무엇을 하고 있는 건가요... 스스로 구멍을 파고 있는 것 아닙니까?
http only가 절대적으로 안전하다는 말은 하지 않았지만, http가 해결할 수 있는 주요 보안 문제는 js가 쿠키를 읽지 못하도록 하는 것입니다. SSL과 협력하면 제3자가 쿠키를 모니터링하는 것을 방지할 수 있습니다(중간자 공격이 아닌 경우).

@WhatAKitty
예전에는 사장님의 입장에서 섰는데, 사실 안전상의 문제가 있어서 다행입니다. 한편으로는 상사가 보안 문제에 주의를 기울이고 다른 한편으로는 정보 보안 엔지니어에게 식사를 남길 것입니다.

정보 보안 엔지니어는 의도적으로 버그를 남겨두는 프로그래머에게 감사해야 합니다. :)

@u0x01 OAuth2를 잘 아시는 것 같은데요? 그룹 생성이 가능한가요?이 분야에서 응용 프로그램 정보를 많이 찾지 못했고 수집 할 시간이 없었습니다.몇 가지 질문을 할 수 있습니다.

@u0x01 백엔드는 stateless이고 세션이 전혀 없습니다. 토큰을 사용하여 만료되었는지 확인하려면 redis를 사용해야 합니다.토큰이 안전한지 여쭤봐도 될까요?

@longzb stateless ≠ 세션 없음, 당신이 언급했습니다

토큰을 사용하여 만료되었는지 여부를 다시 확인하십시오.

실제로 access_token은 세션으로 사용됩니다. 세션의 정의와 작동 방식에 대해 학습하는 것이 좋습니다.

토큰은 어디에 안전한가요?

http_only 쿠키에 넣으면 JS가 쿠키를 직접 획득하는 것을 방지할 수 있으므로 XSS/CSRF 공격의 가치와 가능성을 줄일 수 있습니다.

@u0x01 흠. 어제 바이두에 다녀왔습니다. 쿠키를 넣을거야, 더 안전한게 낫지.

이 기사는 암시적 분석에 대해 좋습니다.
오늘은 SSM+ANTD 샘플을 마무리 하고 있는데, 이 글을 읽고 가장 안전한 방법은 묵시적 ​​서버를 이용하여 인증 서버를 요청하고 토큰을 얻고, 묵시적 서버에 요청하여 해당 서버의 자원을 얻는 것이 가장 안전한 방법이라고 생각합니다. 리소스 서버.

이 기사에서 말했듯이 피싱과 같은 암시적 권한 부여는 위험하기 때문에 해커가 리소스를 요청하기 위해 보안 클라이언트인 척하기 쉽습니다.

하지만 이렇게 하려면 dva가 서버 측 렌더링을 지원해야 합니다. antd가 지원하므로 dva가 이미 지원합니까? @sorrycc

당신은 옳은 일에 대해 걱정하지 않습니다

클라이언트에 있는 정보를 보호하시겠습니까?

정보가 클라이언트(예: 브라우저)에 도달하면 정보를 보호하기 위해 아무 조치도 취할 필요가 없습니다. 액세스 토큰을 쿠키, 웹페이지의 숨겨진 필드, html5 로컬 캐시에 저장할 수 있습니다. 또는 페이지 중앙에 바로 표시되며 아무 것도 변경되지 않습니다(숄더 서핑 제외...).

액세스 토큰이 클라이언트에 있을 때 걱정하는 것은 메모장을 열어 이메일 비밀번호를 쓴 다음 공격자가 원격 위치에서 해당 정보를 훔칠 수 있다고 걱정하는 것과 같습니다. 그런 일은 일어나지 않습니다. 컴퓨터가 이미 손상되지 않은 한 이 시점에서 당신은 이미 잃었습니다.

걱정하는 것이 어디 의미가 있습니까?

일반적으로 귀하의 정보는 전송 중일 때 취약합니다.OAuth2(암시적 흐름)의 경우 액세스 토큰은 다음 두 곳에서 전송됩니다.

인증 서버에서 브라우저로
브라우저에서 리소스 서버로
전송 중에 정보를 보호하는 것은 어디에서나 TLS를 사용하는 것만큼 쉽습니다. OAuth2를 사용하고 있고 프로토콜에서 요구하기 때문에 이미 수행해야 합니다.

이제 진짜 문제

OAuth2를 사용하려는 방식은 OAuth2를 사용해야 하는 방식이 아닐 가능성이 큽니다.

OAuth2를 오용하는 이유를 이해하려면 흐름에 대해 알아야 합니다.

인증 코드(좋은 코드지만... 계속 읽으세요)
암시적(잘못된 보안 감각)
리소스 소유자 암호 자격 증명(끔찍한 생각)
클라이언트 자격 증명(귀하의 경우에는 해당되지 않음)
자바스크립트 클라이언트를 사용하고 있기 때문에 작동하는 유일한 흐름은 암시적 흐름이며 이제 문제를 시작합니다.

암시적 흐름 문제

여러 가지가 있지만 가장 중요한 것에 대해 이야기합시다. 액세스 토큰은 특정 클라이언트에 바인딩되지 않습니다! 사양 섹션 10.16에서:

암시적 흐름을 사용하는 공용 클라이언트의 경우 이 사양은 클라이언트가 액세스 토큰이 발급된 클라이언트를 확인할 수 있는 방법을 제공하지 않습니다.
이렇게 하면 공격자가 리소스 소유자로 가장한 다음 리소스 서버에 액세스할 수 있는 문이 열립니다.섹션 10.16을 계속 읽어 보겠습니다.

리소스 소유자는 공격자의 악의적인 클라이언트에 액세스 토큰을 부여하여 리소스에 대한 액세스 권한을 기꺼이 위임할 수 있습니다. 이는 피싱 또는 기타 구실로 인한 것일 수 있습니다. 공격자는 다른 메커니즘을 통해 토큰을 훔칠 수도 있습니다. 그런 다음 공격자는 다음을 시도할 수 있습니다. 합법적인 공개 클라이언트에 액세스 토큰을 제공하여 리소스 소유자를 가장합니다.

암시적 흐름(response_type=token)에서 공격자는 인증 서버의 응답에서 토큰을 쉽게 전환하여 실제 액세스 토큰을 공격자에게 이전에 발급된 토큰으로 교체할 수 있습니다.

클라이언트의 사용자를 식별하기 위해 백 채널에서 전달된 액세스 토큰에 의존하는 기본 애플리케이션과 통신하는 서버는 임의의 도난된 액세스 토큰을 주입할 수 있는 손상된 애플리케이션을 생성하는 공격자에 의해 유사하게 손상될 수 있습니다.

리소스 소유자만 리소스에 대한 유효한 액세스 토큰을 제공할 수 있다고 가정하는 모든 공개 클라이언트는 이러한 유형의 공격에 취약합니다.
그 첫 번째 공격은 실제로 공격도 아니고 오히려 암시적 흐름의 "결함"일 뿐입니다...

다음 공격

이제 큰 문제가 시작됩니다. OAuth2 암시적 흐름을 제공하지 않는 위임된 최종 사용자 인증 형식으로 사용하려고 하는 것 같습니다. 사양 섹션으로 돌아가기 10.16

클라이언트에 대한 리소스 소유자 인증은 이 사양의 범위를 벗어납니다. 클라이언트에 대한 위임된 최종 사용자 인증의 형태로 권한 부여 프로세스를 사용하는 사양(예: 타사 로그인 서비스)은 다음 없이 암시적 흐름을 사용해서는 안 됩니다(MUST NOT). 클라이언트가 액세스 토큰이 사용을 위해 발행되었는지 확인할 수 있도록 하는 추가 보안 메커니즘(예: 액세스 토큰을 대상으로 제한).
이 시점에서 대부분의 게임은 끝났습니다.

그 공격을 마운트하는 방법?

아주 간단합니다. REST 서비스에 facebook의 액세스 토큰이 필요했다고 가정해 보겠습니다. 공격자가 해야 할 일은 stackoverflow와 같은 서비스를 호스팅하고 facebook의 액세스 토큰을 요구하는 것입니다. facebook 액세스 토큰을 stackoverflow에 제공하면 stackoverflow(공격자)는 이제 REST 서비스로 사용자를 가장할 수 있습니다.

액세스 토큰이 특정 클라이언트에 바인딩되어 있지 않기 때문입니다.

솔루션

암시적 흐름을 사용하지 말고 대신 인증 코드 흐름을 사용하십시오.즉, 100% 클라이언트 측 앱이 더 이상 100% 클라이언트 측 앱이 될 필요가 없습니다.

OAuth2 흐름을 처리하기 위해 사용자에게 angularjs 클라이언트를 제공하는 서버를 사용하지 않는 이유는 무엇입니까?

참조: http://tools.ietf.org/html/rfc6749

@WhatAKitty 각 사용자 브라우저의 특정 식별자가 고유한 경우 사용자가 요청을 보낼 때 이 식별자를 자동으로 가져오며 변경할 수 없습니다.백엔드는 토큰을 처음 신청할 때 이 식별자에 토큰을 바인딩할 수 있습니다. 다음 요청이 토큰에 저장된 브라우저 ID와 일치하지 않으면 불법 요청으로 간주됩니다. .
그래서 묻고 싶습니다. 브라우저가 요청할 때 그러한 로고가 있습니까? ?

@longzb는 일반적으로 JSESSIONID를 사용하거나 사용자 정의할 수 있습니다.예를 들어 oschina는 자신의 id를 사용합니다.

@WhatAKitty @soulmachine @longzb

OAuth2.0의 Password와 Client 모드를 동시에 사용하는 경우 백엔드 서버에 엔트리 프록시를 추가하여 access_token을 저장할 수 있으며, 이 프록시를 프런트엔드 CORS(Spring Boot Oauth2는 CORS의 프리플라이트를 가로채는 것 같습니다)

프론트엔드 비밀번호 모드는 사용자 이름과 비밀번호만 에이전트에게 전송하면 됩니다. 에이전트는 권한을 부여받고 access_token을 저장합니다. 그러면 에이전트가 생성한 SESSION_ID가 프론트엔드로 반환되고 에이전트는 관리해야 합니다. access_token의 만료 및 새로고침 프론트엔드에 노출되는 유일한 것은 Remember- Me 등이 Set-Cookie: Expires= 의 헤드에서 다를 뿐입니다.

클라이언트의 클라이언트 모드는 프록시에만 액세스할 필요가 없으며 인증을 받기 위해 OAuth 인터페이스로 직접 이동합니다.

@u0x01님 답글에 제가

실제로 다음과 같이 요약할 수 있습니다.

1. access_token을 Session 대신 프론트 엔드에 직접 던지는 것은 클라이언트 모드와 인터페이스를 공유해야 하기 때문에 이러한 종류의 인터페이스는 종종 Session 검증을 지원하지 않거나 분산 시스템에서 Session을 관리하는 것이 불편합니다.

2. XSS 및 CSRF 공격에 대한 보안은 별도로 분석해야 합니다.

   2.1 CSRF를 방지하기 위해 프론트엔드는 보낼 HTTP 헤더에 access_token을 넣고 백엔드는 헤더 검증만 지원함과 동시에 인터페이스를 잘 설계하면 된다. 제3자 웹사이트는 폼을 통해서만 추가 HTTP 헤더를 보낼 수 없고, 제3자 웹사이트의 JS는 자체 웹사이트로 데이터를 보낼 수 없기 때문에(CORS가 올바르게 설정된 경우)

   XSS 방지 2.2 프론트 엔드 저장 access_token은 실제로 불안전 마음대로 JS에 의해 판독 영역을 통해 전송 될 수 있으며, 및 쿠키 HttpOnly . 자격 증명 자료 최신 브라우져 매우 도메인 간 제한이 제한되는 집합 엄밀히 말하면 얻을 수 있는 방법이 거의 없습니다. 그러나 최종 분석에서 XSS를 방지한다는 것은 스크립트 주입을 방지하고 신뢰할 수 없는 외부 스크립트를 인용하지 않는 것을 의미해야 하지 않습니까?이 HttpOnly 는 구제 수단이라고 할 수 있습니다

3. 가장 안전한 방법은 백엔드에서 수신 프록시 역할을 하고 CORS의 Access-Control-Allow-Origin 를 설정하여 프론트엔드 도메인 이름만 허용하도록 설정하는 것입니다. 사용자가 성공적으로 로그인하면 HttpOnly 의 세션이 반환되고 헤더 필드에 X-CSRF-TOKEN 와 같은 임의의 코드가 추가됩니다.이 임의의 코드는 OAuth 인터페이스에서 얻은 access_token과 함께 존재합니다. . 프론트엔드는 Ajax나 fetch를 사용하여 Cookie와 이 헤더로 데이터를 보내고, 백엔드는 Cookie의 유효성을 검증한 후 X-CSRF 헤더의 유효성을 검증해야 합니다.이것은 기본적으로 CSRF 및 일반 XSS가 권한을 훔치는 것을 방지할 수 있습니다.

요컨대, access_token의 프런트 엔드 관리는 무례하게 안전하지 않은 것으로 간주될 수 없습니다.

업데이트 1:

미들웨어 또는 백엔드는 jwt를 사용하여 access_token을 암호화함과 동시에 XSS를 방지하기 위해 주입 감지 및 CSP를 형성합니다.

@mdluo 명쾌한 아이디어가 있습니다, 칭찬합니다 👍

@mdluo 죄송합니다. 저는 프론트 엔드의 초보자입니다. 언급한 세 번째 방법에서는 기본적으로 Spring boot + spring security로 백엔드 부분을 달성할 수 있지만 프론트 엔드 페치에 쿠키를 가져오려면 어떻게 해야 합니까? 크로스 도메인을 포함하기 때문에 인터넷의 일부 솔루션에서는 credentials: "include" 매개변수를 사용하여 해결하지만 이 매개변수는 GET 요청만 해결할 수 있습니다. POST 및 기타 문제에는 문제가 있습니다. 처음 사용하기 때문에 직접 작성하는 것은 어리석은 일입니다. 환경은 다음과 같습니다.
프런트 엔드: DVA 포트 8000
백엔드: 스프링 부트 + 스프링 보안, X-CSRF-TOKEN 및 쿠키

@yoster0520 백엔드에 CORS 설정 프론트엔드에 여러 주소가 있는 경우 백엔드는 쿠키를 가져올 수 있도록 화이트리스트에 따라 Access-Control-Allow-Origin 만 동적으로 결정하여 반환해야 합니다.