인증은 HTTP 요청에서 사용자 ID 확인을 처리하는 웹 애플리케이션의 중요한 구성 요소입니다. ASP.NET Framework에서 ASP.NET Core로 마이그레이션하는 경우 두 프레임워크가 인증을 매우 다르게 처리하기 때문에 인증에 고유한 문제가 발생합니다.
ASP.NET Core의 인증에 대한 일반적인 내용은 ASP.NET Core 인증 개요를 참조하세요. 권한 부여에 대한 자세한 내용은 ASP.NET Core의 권한 부여 소개를 참조하세요.
인증 마이그레이션이 복잡한 이유
ASP.NET Framework 및 ASP.NET Core에는 인증에 대한 근본적으로 다른 접근 방식이 있습니다.
- ASP.NET Framework 는 System.Web과 자동 구성 및 긴밀한 통합이 포함된 기본 제공 인증 모듈을 제공합니다.
- ASP.NET Core 는 명시적 구성 및 종속성 주입을 통해 미들웨어 기반 접근 방식을 사용합니다.
이러한 차이는 단순히 변경 없이 인증 코드를 프레임워크에서 Core로 이동할 수 없다는 것을 의미합니다.
인증 유형 및 마이그레이션 문제
다양한 인증 유형은 마이그레이션 복잡성의 다양한 수준을 제공합니다.
Cookie 기반 인증
-
ASP.NET Framework: 인증 미들웨어 사용
Microsoft.Owincookie -
ASP.NET Core: 다른 구성으로 미들웨어 사용
CookieAuthentication - 마이그레이션 과제: Cookie 형식, 암호화 키 및 구성 차이점
JWT 전달자 토큰
- ASP.NET Framework: 사용자 지정 모듈 또는 OWIN 미들웨어를 통해 처리되는 경우가 많습니다.
-
ASP.NET Core:
Microsoft.AspNetCore.Authentication.JwtBearer을 통한 본래의 지원 - 마이그레이션 과제: 토큰 유효성 검사 매개 변수 차이점 및 미들웨어 등록
Windows 인증
- ASP.NET Framework: 기본 제공 IIS 통합
- ASP.NET Core: 명시적 구성이 필요하며 호스팅 모델 변경이 필요할 수 있습니다.
- 마이그레이션 과제: 서버 구성 및 인증 흐름 차이
폼 인증
-
ASP.NET Framework: 기본 제공
System.Web.Security.FormsAuthentication - ASP.NET Core: 직접 동등한 항목이 없으므로 인증으로 마이그레이션해야 합니다 cookie .
- 마이그레이션 과제: 필요한 인증 시스템 다시 쓰기 완료
사용자 지정 인증
-
ASP.NET Framework: 구현하는 사용자 지정 모듈
IHttpModule - ASP.NET Core: 사용자 지정 미들웨어 또는 인증 처리기
- 마이그레이션 과제: 모듈에서 미들웨어로 아키텍처 변경 완료
마이그레이션 전략 개요
마이그레이션 중에 인증을 처리하는 세 가지 주요 접근 방식이 있습니다.
- 다시 쓰기 완료 - ASP.NET Core의 네이티브 인증을 사용하도록 모든 인증 코드 다시 쓰기
- 원격 인증 - System.Web 어댑터를 사용하여 ASP.NET Framework 앱에 인증 위임
- 공유 cookie 인증 - Framework와 Core 애플리케이션 간에 인증 쿠키 공유(OWIN 기반 시나리오의 경우)
대부분의 애플리케이션에서 네이티브 ASP.NET Core 인증으로 마이그레이션하면 최상의 성능과 유지 관리가 제공됩니다. 그러나 더 큰 애플리케이션 또는 복잡한 인증 요구 사항이 있는 애플리케이션은 System.Web 어댑터를 사용하는 증분 접근 방식의 이점을 누릴 수 있습니다.
마이그레이션 접근 방식 선택
ASP.NET Framework에서 ASP.NET Core로 인증을 마이그레이션하는 세 가지 주요 옵션이 있습니다. 선택 항목은 인증 유형, 마이그레이션 타임라인, 두 애플리케이션을 동시에 실행해야 하는지 여부 및 다시 작성하려는 코드 양에 따라 달라집니다.
빠른 의사 결정 가이드
다음 질문에 대답하여 접근 방식을 선택합니다.
전체 다시 쓰기 또는 증분 마이그레이션을 수행하고 있나요?
- 다시 쓰기 → 다시 쓰기를 완료하여 ASP.NET Core 인증
- 증분 마이그레이션 → 질문 2로 계속
ASP.NET Framework 앱에서 사용하는 인증 유형은 무엇인가요?
- OWIN cookie 인증 → 계속 질문 3
- 폼 인증, JWT 전달자 토큰, Windows 인증 또는 사용자 지정 인증 → 원격 인증
ASP.NET Framework 및 ASP.NET Core 앱 모두 동일한 인증 상태에 액세스해야 합니까?
- 예, 공유 인증 필요 → 계속 질문 4
- 별도의 인증은 괜찮습니다. → ASP.NET Core 인증으로 완전히 다시 작성 완료
두 앱 간에 일치하는 데이터 보호 설정을 구성할 수 있나요?
- 예 → 공유 cookie 인증 (대체 섹션 참조, 최상의 성능)
- 원격 인증을 → 없음 또는 확실하지 않음
마이그레이션 접근 방식 비교
| 접근법 | 코드 변경 내용 | 성능 | 인증 공유 | 사용 시기 |
|---|---|---|---|---|
| 다시 쓰기 완료 | 높음 - 모든 인증 코드 다시 쓰기 | 최상의 | 없음 | 전체 다시 쓰기, 성능에 중요한 앱, 비 OWIN 인증 |
| 원격 인증 | 낮음 - 기존 패턴 유지 | 보통 | 전체 | 증분 마이그레이션, 복잡한 인증, Windows 인증 |
| 공유 쿠키 | 중간 - 구성 업데이트 | 좋음 | 전체 | OWIN cookie 인증, 성능에 중요한 공유 인증(대안 참조) |
ASP.NET Core 인증에 다시 쓰기 완료
전체 마이그레이션을 수행하거나, OWIN이 아닌 인증을 사용하거나, 최상의 성능과 유지 관리를 원하는 경우 이 방법을 선택합니다.
ASP.NET Core는 고성능 및 광범위한 사용자 지정 옵션을 통해 포괄적인 인증 지원을 제공합니다. 이 방법을 사용하려면 인증 코드를 다시 작성해야 하지만 장기적으로 가장 많은 이점을 제공합니다.
전체 다시 쓰기 장단점
| 장점 | 단점 |
|---|---|
| 최상의 성능 및 보안 | 모든 인증 코드를 다시 작성해야 함 |
| 네이티브 ASP.NET Core 구현 | 자동 마이그레이션 경로 없음 |
| 인증 흐름에 대한 모든 권한 | 새 인증 패턴에 대한 학습 곡선 |
| 추가 종속성 없음 | 프레임워크 패턴의 호환성을 깨뜨리는 변경 |
| 최신 ASP.NET Core 인증 기능에 대한 액세스 | 마이그레이션 중 잠재적인 가동 중지 시간 |
마이그레이션 고려 사항
네이티브 ASP.NET Core 인증으로 마이그레이션하는 경우:
프레임워크 인증 유형에 따라 선택합니다.
- 인증으로 마이그레이션 Cookie → 양식 인증
- JWT 전달자 토큰 →JWT 전달자 인증으로 마이그레이션
- Windows 인증 → Windows 인증 사용
- OWIN OAuth 공급자 → 해당 ASP.NET Core OAuth 공급자 사용
- 사용자 지정 인증 → 사용자 지정 인증 처리기 구현
코드 변경 필요:
- 액세스 패턴 바꾸기
HttpContext.User(대부분 호환 가능) - 인증 미들웨어 등록을
Program.cs에서 업데이트하세요. - 사용자 지정 인증 논리를 ASP.NET Core 패턴으로 마이그레이션
- 권한 부여 특성 및 정책 업데이트
이 방법을 선택하는 경우:
- 인증 관련 코드를 다시 작성할 수 있습니다.
- 성능이 최우선 순위입니다.
- 레거시 애플리케이션과 인증 상태를 공유하지 않습니다.
- System.Web 종속성을 완전히 제거하려고 합니다.
- 프레임워크 앱은 Forms 인증, 사용자 지정 모듈 또는 JWT 토큰을 사용합니다.
원격 인증
비고
이렇게 하면 System.Web 어댑터를 사용하여 마이그레이션을 간소화할 수 있습니다.
증분 마이그레이션 중에 ASP.NET Framework와 ASP.NET Core 애플리케이션 간에 인증을 공유해야 하거나 마이그레이션하기 어려운 복잡한 인증이 있는 경우 이 방법을 선택합니다.
System.Web 어댑터의 원격 인증 기능을 사용하면 ASP.NET Core 앱이 ASP.NET 앱으로 지연하여 사용자의 ID를 확인할 수 있습니다. 이렇게 하면 단일 인증 시스템을 유지하면서 점진적인 마이그레이션을 수행할 수 있습니다.
원격 인증 작동 방식
- ASP.NET Core 앱에서 요청을 처리할 때 원격 앱 인증이 기본 구성표이거나 요청의 엔드포인트에 의해 지정된 경우
RemoteAuthenticationAuthHandler는 사용자를 인증하려고 시도합니다. - 처리기는 ASP.NET 앱의 인증 엔드포인트에 HTTP 요청을 수행하여 현재 요청(기본적으로
AuthorizationCookie헤더)에서 구성된 헤더를 전달합니다. - ASP.NET 앱은 인증을 처리하고 오류를 나타내는 직렬화된
ClaimsPrincipal또는 HTTP 상태 코드를 반환합니다. - ASP.NET Core 앱은 결과를 사용하여 사용자의 ID를 설정하거나 인증 문제를 처리합니다.
원격 인증 장단점
| 장점 | 단점 |
|---|---|
| 필요한 최소 코드 변경 | 추가 HTTP 요청 오버헤드 |
| 모든 프레임워크 인증 형식에서 작동 | 앱 간의 네트워크 종속성 |
| 점진적 마이그레이션 기능 | 더 복잡한 디버깅 |
| 기존 인증 논리를 유지합니다. | 두 앱을 모두 실행해야 합니다. |
| 복잡한 인증 시나리오 처리 | 제한된 Windows 인증 지원 |
원격 인증을 선택하는 경우
다음과 같은 경우 원격 인증을 선택합니다.
- ASP.NET 앱은
Microsoft.Owincookie 인증을 사용하지 않습니다. - 다양한 인증 메커니즘을 사용하는 유연한 솔루션을 원합니다.
- 인증 논리를 ASP.NET Core로 점진적으로 마이그레이션해야 합니다.
- 다시 쓰기 어려운 복잡한 사용자 지정 인증이 있습니다.
- 증분 마이그레이션을 수행하고 있으며 공유 인증 상태가 필요합니다.
원격 인증 구성
시작에 따라 이미 설정된 솔루션에서 원격 인증을 사용하도록 설정하는 데 필요한 몇 가지 작은 코드 변경만 있습니다.
먼저 원격 앱 설정 지침에 따라 ASP.NET Core 및 ASP.NET 앱을 연결합니다. 그런 다음 원격 앱 인증을 사용하도록 설정하기 위해 호출할 몇 가지 추가 확장 메서드가 있습니다.
ASP.NET 앱 구성
ASP.NET 앱은 인증 엔드포인트를 추가하도록 구성해야 합니다. 인증 엔드포인트를 추가하려면 확장 메서드를 AddAuthenticationServer 호출하여 인증 엔드포인트에 대한 요청을 감시하는 HTTP 모듈을 설정합니다. 원격 인증 시나리오는 일반적으로 프록시 지원을 추가하려고 하므로 인증 관련 리디렉션이 ASP.NET 앱이 아닌 ASP.NET Core 앱으로 올바르게 라우팅됩니다.
HttpApplicationHost.RegisterHost(builder =>
{
builder.AddSystemWebAdapters()
.AddProxySupport(options => options.UseForwardedHeaders = true)
.AddRemoteAppServer(options =>
{
options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
})
.AddAuthenticationServer();
});
ASP.NET Core 앱 구성
다음으로, ASP.NET 앱에 대한 HTTP 요청을 수행하여 사용자를 인증하는 인증 처리기를 사용하도록 ASP.NET Core 앱을 구성해야 합니다. 이 작업은 System.Web 어댑터 서비스를 등록할 때 AddAuthenticationClient를 호출하여 진행됩니다.
builder.Services.AddSystemWebAdapters()
.AddRemoteAppClient(options =>
{
options.RemoteAppUrl = new Uri(builder.Configuration
["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
options.ApiKey = builder.Configuration["RemoteAppApiKey"];
})
.AddAuthenticationClient(true);
AddAuthenticationClient 호출에 전달되는 부울은 원격 앱 인증이 기본 인증 체계인지 여부를 지정합니다.
true를 전달하면 사용자가 모든 요청에 대해 원격 앱 인증을 통해 인증되는 반면, false를 전달하면 원격 앱 구성표가 특별히 요청된 경우에만 사용자가 원격 앱 인증으로 인증됩니다(예: 컨트롤러 또는 작업 방법에 [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] 포함). 이 매개 변수에 대해 false를 전달하면 원격 앱 인증이 필요한 엔드포인트에 대한 인증을 위해 원래 ASP.NET 앱에 HTTP 요청만 수행할 수 있다는 장점이 있지만 원격 앱 인증을 사용한다는 것을 나타내려는 경우 이러한 모든 엔드포인트에 주석을 추가해야 하는 단점이 있습니다.
사용하는 Aspire경우 구성은 환경 변수를 통해 수행되며 AppHost에 의해 설정됩니다. 원격 세션을 사용하려면 다음 옵션을 사용하도록 설정해야 합니다.
...
var coreApp = builder.AddProject<Projects.AuthRemoteIdentityCore>("core")
.WithHttpHealthCheck()
.WaitFor(frameworkApp)
.WithIncrementalMigrationFallback(frameworkApp, options => options.RemoteAuthentication = RemoteAuthentication.DefaultScheme);
...
이 작업이 완료되면 프레임워크와 핵심 애플리케이션 모두에서 자동으로 연결됩니다.
YARP 대체를 사용한 원격 인증
ASP.NET Framework 앱에 YARP 기반 대체를 사용하여 원격 인증을 사용하는 경우 대체 요청이 원격 인증을 호출하지 않는지 확인합니다. 대체 중에 원격 인증이 실행되는 경우 앱은 프레임워크 앱에 불필요한 추가 호출을 수행하고 혼란스러운 동작을 초래할 수 있습니다.
대체 요청에 대해 원격 인증을 실행하지 않도록 하려면 다음 방법 중 하나를 사용합니다.
- 경로가 나머지 미들웨어 파이프라인을 우회하도록 YARP 대체 경로에서 라우팅 단락 메타데이터를 사용합니다. 예를 들어, 원격 앱 설정 지침 대로 대체 엔드포인트에서
를 호출하고 라우팅 후 숏 서킷 미들웨어 에 표시된 대로 실행합니다. - 원격 인증을 기본 인증 체계로 사용하지 마세요. 대신 필요한 엔드포인트에 대해서만 원격 인증을 구성합니다. 예를 들어
false을AddAuthenticationClient에 전달하고, 해당 엔드포인트에서 원격 인증 체계를 명시적으로 지정합니다.
특정 엔드포인트에서 원격 인증 사용
기본 체계 false를 설정하면 특정 컨트롤러 또는 작업에 대한 원격 인증을 지정할 수 있습니다.
[Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
public class SecureController : Controller
{
// This controller uses remote authentication
public IActionResult Index()
{
return View();
}
}
// Or on specific actions
public class HomeController : Controller
{
[Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
public IActionResult SecureAction()
{
return View();
}
}
사용자 지정 인증 결과 프로세서 구현
사용자 지정 프로세서를 구현하여 인증 결과를 사용하기 전에 수정할 수 있습니다.
public class CustomAuthResultProcessor : IRemoteAuthenticationResultProcessor
{
public Task ProcessAsync(RemoteAuthenticationResult result, HttpContext context)
{
// Custom logic to process authentication results
if (result.Headers.ContainsKey("Location"))
{
// Modify redirect URLs or other logic
}
return Task.CompletedTask;
}
}
// Register the custom processor
builder.Services.AddScoped<IRemoteAuthenticationResultProcessor, CustomAuthResultProcessor>();
마지막으로, ASP.NET Core 앱에 이전에 인증 미들웨어가 포함되지 않았다면, 먼저 라우팅 미들웨어를 활성화한 후, 인증 미들웨어를 활성화하고, 그 다음에 권한 부여 미들웨어를 활성화해야 합니다. 미들웨어 순서 지정에 대한 자세한 내용은 ASP.NET Core 미들웨어를 참조하세요.
app.UseAuthentication();
보안 고려사항
원격 인증을 구현할 때 다음 보안 측면을 고려합니다.
- API 키 보안: ASP.NET Core와 ASP.NET 앱 간의 통신에 사용되는 API 키는 구성 공급자 를 사용하여 안전하게 저장되어야 하며 하드 코딩되지 않아야 합니다.
- 네트워크 보안: 프로덕션 환경의 HTTPS(보안 채널)를 통해 앱 간 통신이 수행되어야 합니다.
- 헤더 전달: 중요한 정보가 노출되지 않도록 전달되는 헤더에 주의해야 합니다. 인증에 필요한 헤더만 전달합니다.
- Endpoint Protection: ASP.NET 앱의 인증 엔드포인트는 외부 클라이언트가 아닌 ASP.NET Core 앱에서만 액세스할 수 있어야 합니다.
문제 해결
원격 인증을 구성할 때 발생하는 일반적인 문제:
- 인증 실패: API 키가 두 애플리케이션 간에 일치하고 인증 엔드포인트 경로가 올바르게 구성되었는지 확인합니다.
-
리디렉션 루프: ASP.NET 앱이 아닌 ASP.NET Core 앱으로 리디렉션하도록 올바르게 구성되었는지 확인
RedirectUrlProcessor합니다. -
누락된 클레임: ASP.NET 앱이 제대로 직렬화
ClaimsPrincipal되고 있으며 필요한 모든 클레임이 포함되어 있는지 확인합니다.
디자인
- ASP.NET Core 앱에서 요청을 처리할 때 원격 앱 인증이 기본 구성표이거나 요청의 엔드포인트에 의해 지정된 경우
RemoteAuthenticationAuthHandler는 사용자를 인증하려고 시도합니다.- 처리기는 ASP.NET 앱의 인증 엔드포인트에 대한 HTTP 요청을 수행합니다. 인증 관련 데이터를 전달하기 위해 현재 요청에서 이 새 헤더로 구성된 헤더를 복사합니다. 위에서 설명한 대로 기본 동작은
Authorization및Cookie헤더를 복사하는 것입니다. API 키 헤더도 보안을 위해 추가됩니다.
- 처리기는 ASP.NET 앱의 인증 엔드포인트에 대한 HTTP 요청을 수행합니다. 인증 관련 데이터를 전달하기 위해 현재 요청에서 이 새 헤더로 구성된 헤더를 복사합니다. 위에서 설명한 대로 기본 동작은
- ASP.NET 앱은 인증 엔드포인트로 전송된 요청을 처리합니다. API 키가 일치하는 한 ASP.NET 앱은 현재 사용자의 ClaimsPrincipal 직렬화된 응답 본문을 반환하거나 HTTP 상태 코드(예: 401 또는 302)와 실패를 나타내는 응답 헤더를 반환합니다.
- ASP.NET Core 앱이
RemoteAuthenticationAuthHandlerASP.NET 앱에서 응답을 수신하는 경우:- ClaimsPrincipal이 성공적으로 반환된 경우 인증 처리기는 이를 역직렬화하고 현재 사용자의 ID로 사용합니다.
- ClaimsPrincipal이 성공적으로 반환되지 않은 경우 처리기는 결과를 저장하고 인증에 문제가 있는 경우(예: 사용자가 보호된 리소스에 액세스하고 있기 때문에) 요청의 응답은 상태 코드와 인증 엔드포인트의 응답에서 선택한 응답 헤더로 업데이트됩니다. 이를 통해 최종 사용자에게 챌린지 응답(예: 로그인 페이지로 리디렉션)을 전파할 수 있습니다.
- ASP.NET 앱의 인증 엔드포인트의 결과에는 엔드포인트와 관련된 데이터가 포함될 수 있으므로 사용자는 사용에 앞서 모든 인증 결과에서 실행되는 ASP.NET Core 앱에
IRemoteAuthenticationResultProcessor구현을 등록할 수 있습니다. 예를 들어 하나의 기본 제공IRemoteAuthenticationResultProcessor는 인증 엔드포인트에서 반환된RedirectUrlProcessor응답 헤더를 찾고 ASP.NET 앱이 아닌 ASP.NET Core 앱의 호스트로 다시 리디렉션되도록 하는Location입니다.
- ASP.NET 앱의 인증 엔드포인트의 결과에는 엔드포인트와 관련된 데이터가 포함될 수 있으므로 사용자는 사용에 앞서 모든 인증 결과에서 실행되는 ASP.NET Core 앱에
알려진 제한 사항
이 원격 인증 방법에는 다음과 같은 몇 가지 알려진 제한 사항이 있습니다.
- Windows 인증: Windows 인증은 Windows ID에 대한 핸들에 따라 달라지므로 이 기능에서 Windows 인증을 지원하지 않습니다. 향후 작업은 공유 Windows 인증의 작동 방식을 검색하도록 계획하고 있습니다. 자세한 내용은 dotnet/systemweb-adapters#246을 참조하세요. Windows 인증 시나리오의 경우 ASP.NET Core 애플리케이션에서 ASP.NET Core에서 Windows 인증 구성 을 대신 사용하는 것이 좋습니다.
- 사용자 관리 작업: 이 기능을 사용하면 ASP.NET Core 앱이 ASP.NET 앱에서 인증된 ID를 사용할 수 있지만 사용자와 관련된 모든 작업(로그온, 로그오프 등)은 여전히 ASP.NET 앱을 통해 라우팅되어야 합니다.
- 성능 고려 사항: 각 인증 요청에는 성능에 영향을 미칠 수 있는 ASP.NET 앱에 대한 HTTP 호출이 필요합니다. 성능이 중요한 경우 공유 cookie 인증(대체 섹션에 설명)을 사용하는 것이 좋습니다.
공유 cookie 인증
ASP.NET 앱의 인증이 인증 미들웨어를 사용하여 Microsoft.OwinCookie 수행되는 경우 원격 인증에 대한 대체 솔루션은 인증을 공유할 cookie수 있도록 ASP.NET 및 ASP.NET Core 앱을 구성하는 것입니다.
공유 쿠키 작동 방식
인증 cookie를 공유하면 다음을 수행할 수 있습니다.
- 두 앱 모두 동일한 cookie에서 사용자 신원을 확인합니다.
- 한 앱에서 로그인 또는 로그아웃하면 사용자가 다른 앱에서도 로그인하거나 로그아웃합니다.
두 애플리케이션은 다음으로 구성됩니다.
- 동일한 cookie 이름 및 도메인 설정 사용
- 암호화/암호 해독을 위한 cookie 데이터 보호 키 공유
- 호환되는 cookie 인증 미들웨어 사용
이렇게 하면 한 앱에서 인증된 사용자가 요청을 할 때 다른 앱에서 자동으로 인증될 수 있습니다.
공유 cookie 인증 장단점
| 장점 | 단점 |
|---|---|
| 공유 인증에 대한 최상의 성능 | OWIN cookie 인증에서만 작동합니다. |
| 추가 HTTP 요청 없음 | 일치하는 데이터 보호 설정 필요 |
| 두 앱 모두 로그인/로그아웃을 처리할 수 있습니다. | 더 복잡한 초기 구성 |
| 원활한 사용자 환경 | cookie 기반 인증으로 제한됨 |
| 네트워크 오버헤드 감소 | 배포 조정 필요 |
공유 쿠키를 사용한 인증 제한 사항
로그인은 일반적으로 특정 데이터베이스에 따라 달라지므로 모든 인증 기능이 두 앱에서 모두 작동하는 것은 아닙니다.
- 사용자는 ASP.NET 또는 ASP.NET Core 앱 중 데이터베이스가 작동하도록 설정되어 있는 하나만을 통해 로그인해야 합니다.
- 두 앱 모두 사용자의 ID와 클레임을 볼 수 있습니다.
- 두 앱 모두 사용자를 로그아웃할 수 있습니다.
ASP.NET 및 ASP.NET Core 앱 간에 인증 쿠키 공유를 구성하는 방법에 대한 자세한 내용은 공유 설명서cookie 확인할 수 있습니다. ASP.NET Core의 인증에 대한 cookie 자세한 내용은 ASP.NET Core 없이 인증 사용을 cookie 참조하세요 Identity. Framework 및 Core 앱 간에 보호된 값을 공유할 때 구성 <machineKey> 및 데이터 보호에 대한 지침은 ASP.NET Core 마이그레이션을 위한 ASP.NET machineKey를 참조하세요.
System.Web 어댑터 GitHub 리포지토리의 다음 샘플에서는 두 앱이 사용자를 로그인 및 로그아웃할 수 있도록 하는 공유 cookie 구성을 사용하여 원격 앱 인증을 보여 줍니다.
- 앱 ASP.NET
- ASP.NET Core 앱
공유 cookie 인증을 선택하는 경우
다음 경우에 공유 Cookie 인증을 선택합니다.
- ASP.NET 앱에서 이미 인증을 사용하고 있습니다.
Microsoft.Owincookie - 두 앱 간에 일치하는 데이터 보호 설정을 구성할 수 있습니다.
- 성능이 중요하며 HTTP 요청을 최소화하려고 합니다.
- 두 앱 모두 사용자 로그인/로그아웃 작업을 처리하려고 합니다.
- 공유 암호화 키를 관리하는 것이 편합니다.
다음 두 가지 모두 true인 경우 인증을 공유하는 것이 좋습니다.
- ASP.NET 앱이 이미
Microsoft.Owincookie 인증을 사용하고 있습니다. - ASP.NET 앱 및 ASP.NET Core 앱을 업데이트하여 일치하는 데이터 보호 설정을 사용할 수 있습니다. 일치하는 공유 데이터 보호 설정에는 데이터 보호 키를 저장하기 위한 공유 파일 경로, Redis 캐시 또는 Azure Blob Storage가 포함되어 있습니다. 자세한 내용은 ASP.NET Core 데이터 보호 개요를 참조하세요.
기타 시나리오의 경우 이 문서의 앞에서 설명한 원격 인증 접근 방식이 더 유연하며 더 적합할 수 있습니다.
참고하십시오
ASP.NET Core