일반 폼 인증 외에도 WebClient 개체가 Thinktecture IdentityModel을 사용하여 설정된 웹 API DAL이 제공하는 API/토큰 URL에 대한 기본 인증을 수행하도록 폼 인증 로그인 프로세스를 수정하는 것이 어렵지 않습니다 . 반환 된 세션 토큰은 나중에 DAL을 호출 할 때 사용할 수 있도록 세션 사전에 저장 될 수 있습니다.브리징 폼 인증 및 OAUTH
문제는 이러한 토큰의 수명이 다릅니다.
필요에 따라 세션 토큰을 다시 생성하기 위해 localStorage에서 자격 증명을 유지하도록 응용 프로그램을 다시 작성할 수는 있지만 보안 측면에서는보기에 좋지 않습니다.
아마도 이러한 시스템 중 하나 또는 둘 모두에서 토큰 내구성을 구성 할 수있는 방법이 있지만 사용할 토큰 내구성 및 토큰 수명을 검색하려했지만 결과가 도움이되지 않았습니다.
두 가지 유형의 웹 앱 보안을 조정하는 최선의 방법에 대한 철학적 및 실용적인 제안에 관심이 있습니다. 나는이 주제에 대해 이미 답을 찾지 못했다면, 내가 무엇을 검색해야할지 알았다면 매우 놀랄 것입니다.
일부 사람들은 내가 묻는 것에 대해 명확하지 않기 때문에 약간의 배경 지식이 있습니다.
Thinktecture IdentityModel를 사용하는 별도의 DAL 응용 프로그램으로 폼 기반 보안
난 그냥 추가 한 새로운 재료를 사용하는 큰 추악한 오래된 학교 ASP.NET 웹 응용 프로그램이있다. 이 DAL은 두 개의 응용 프로그램 인 ASP.NET 응용 프로그램과 Durandal SPA에서 사용됩니다.
신원 확인에 동일한 데이터베이스를 사용하므로 ID 공간이 동일합니다.
이전 앱의 로그인 프로세스가 수정되어 Thinktable IdentityModel에서 자격 증명을 제시하고 세션 토큰을 얻습니다. 이 토큰은 이전 앱이 DAL을 호출 할 때마다 표시 될 Session 컬렉션에 삽입됩니다.
이전 응용 프로그램을 시작하고 물건을 채우고 브라우저를 닫은 다음 브라우저를 다시 연 다음 로그인하지 않은 로그인 한 ASP.NET 응용 프로그램이 없으므로 세션 토큰을 만들 수 없습니다. 이게 문제 야. 동일한 라이프 사이클을 사용하려면 두 개의 토큰이 필요합니다.
나는 가능한 접근법을 생각해 보았습니다. 나는 사람들이 그 공로에 대해 그들의 의견을 표현하거나 세련된 제안 의견을 낼 수 있도록 대답으로 아래에 제시 할 것입니다. 다른 아이디어를 생각하면 대답으로 던져 버리고 똑같이 할 수 있기를 바랍니다.
두 토큰에 대해 짧은 토큰의 수명을 사용할 수없는 이유가 있습니까? 첫 번째 만료시 재 인증이 필요하며 수명이 더 긴 토큰을 폐기하거나 그냥 교체하십시오. – mpowered
당신이 찾고있는 것은 auth token expiration configuration입니다. 그러나 귀하의 질문은 귀하가하고있는 일과 귀하가 습득하려고 시도하고있는 것에 대한 세부 사항이 매우 낮습니다. 왜 OAUTH 토큰으로 localStorage (클라이언트 측)를 사용했으며 auth (서버 측)도 작성 했습니까? – Bishoy