우리는 MVC 애플리케이션을 가지고 있습니다. MVC 애플리케이션은 브라우저에서 웹 API 호출을 통해 데이터를 가져 와서 브라우저에 표시합니다. 우리의 응용 프로그램은 클레임 인식이므로 클라이언트는 웹 API에 액세스하기 위해 AccessToken을 전달해야합니다. 브라우저가 신뢰할 수있는 클라이언트가 아니기 때문에 (서버가 브라우저를 제어하지 못하기 때문에) 클라이언트 (브라우저)가 AccessToken을 저장하는 것이 좋습니다? 보안을 해치지 않으면 서 더 나은 디자인 패턴이 있습니까?클라이언트 (브라우저)에 대한 AccessToken 공유는 보안 문제입니까?
브라우저를 어느 정도 신뢰해야합니다. 그렇지 않으면 웹 응용 프로그램이별로 쓸모가 없습니다. 토큰 및 API를 사용하기 전에 기존 서버 측 응용 프로그램은 브라우저에서 브라우저에 세션 식별자를 저장할 수 있다고 신뢰할 수있었습니다.
토큰을 사용하면 원칙은 동일하지만 악마가 자세히 나와 있습니다. 우선, HTTPS를 사용해야한다고 가정하십시오. 그렇지 않으면 포기할 수도 있습니다. HTTPS를 적절한 위치에두면 브라우저에 액세스 토큰 및/또는 쿠키를 안전하게 전송할 수 있다고 가정 할 수 있습니다.
그런 다음 브라우저에서 사용할 저장소의 특성에 대해 걱정할 필요가 있습니다. 이를 위해 토큰을 저장할 위치를 읽어 볼 것을 권장합니다. Cookies vs Tokens: The Definitive Guide 기사의 섹션
실제 문제는 정해진 목록을 제공하는 것이 거의 불가능한 다른 작은 세부 사항이 충분하며 작은 세부 정보이지만 시스템의 전체 보안에 큰 영향을 줄 수 있다는 것입니다. 유일한 정직한 권고는 당신이 자신의 인증 시스템을 사용하기를 원한다면 준비가 필요하므로 이러한 모든 세부 사항을 배우는 데 상당한 시간과 자원을 소비해야한다는 것입니다.
액세스 토큰 (JWT 토큰)이 클라이언트 측에 저장되는 경우 재생 공격은 어떻게됩니까? XSS 및 CSRF 공격? 토큰의 유효 기간은 만료되지만 공격 창이 발생한다는 것에 동의합니다. 브라우저에 JWT 토큰을 저장하고 관리하는 책임을 부여하는 방식이 공격 범위를 증가시킵니다. 보안 관점에서 의견이 있으십니까? –
@Venkat Naidu, 공격 표면이 실제로 증가하지만 대안은 무엇입니까? 토큰 기반 인증을 사용하는 API에 인증 된 요청을 수행 할 수있는 브라우저 응용 프로그램을 원할 경우 클라이언트 쪽에서 토큰 서버 측에 매핑되는 세션 ID를 저장하고 서버 또는 토큰 자체를 호출하고 클라이언트에서 호출을 수행하십시오. 쿠키 또는 토큰, 같은 공격 표면. –