ASP.NET Core 인증 개요

Mike Rousos 작성

인증은 사용자 ID를 확인하는 프로세스입니다. 권한 부여는 사용자에게 리소스에 대한 액세스 권한이 있는지를 확인하는 프로세스입니다. ASP.NET Core에서는 인증이 인증 미들웨어에서 사용되는 인증 서비스, IAuthenticationService를 사용하여 처리됩니다. 인증 서비스는 등록된 인증 처리기를 사용하여 인증 관련 작업을 완료합니다. 인증 관련 작업의 예는 다음과 같습니다.

• 사용자 인증.
• 인증되지 않은 사용자가 제한된 리소스에 액세스하려고 할 때 응답합니다.

등록된 인증 처리기와 해당 구성 옵션을 "체계"라고 합니다.

인증 체계는 Program.cs에 인증 서비스를 등록하여 지정됩니다.

• AddAuthentication(예: AddJwtBearer 또는 AddCookie)을 호출한 후에 스키마별 확장 메서드를 호출합니다. 이러한 확장 메서드는 적절한 설정으로 스키마를 등록하는 데 사용합니다 AuthenticationBuilder.AddScheme .
• 덜 일반적으로 직접 호출 AuthenticationBuilder.AddScheme 하여.

예를 들어, 다음 코드는 cookie 및 JWT 전달자 인증 체계의 인증 서비스와 처리기를 등록합니다.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

AddAuthentication 매개 변수 JwtBearerDefaults.AuthenticationScheme는 특정 체계가 요청되지 않은 경우 기본적으로 사용할 체계의 이름입니다.

여러 스키마를 사용하는 경우, 권한 부여 정책(또는 권한 부여 특성)은 사용자를 인증하기 위해 사용해야 하는 인증 체계(또는 체계)를 지정할 수 있습니다. 위의 예제에서, cookie 인증 체계는 이름을 지정하여 사용할 수 있습니다(AddCookie를 호출할 때 다른 이름을 제공할 수 있지만 기본적으로 CookieAuthenticationDefaults.AuthenticationScheme).

경우에 따라, AddAuthentication에 대한 호출은 다른 확장 메서드에서 자동으로 수행됩니다. 예를 들어, ASP.NET Core Identity를 사용하는 경우 AddAuthentication이 내부적으로 호출됩니다.

인증 미들웨어는 Program.cs에서 UseAuthentication을 호출하여 추가됩니다. UseAuthentication을 호출하면 이전에 등록된 인증 체계를 사용하는 미들웨어가 등록됩니다. 인증되는 사용자에 따라 달라지는 미들웨어 이전에 UseAuthentication을(를) 호출합니다.

인증 개념

인증은 사용 권한을 결정할 권한 부여에 대해 ClaimsPrincipal을 제공합니다. 올바른 클레임 세트 생성을 담당하는 인증 처리기를 선택하는 방법으로 여러 가지 인증 체계가 있습니다.

• 인증 체계
• 기본 인증 체계는 다음 섹션에서 설명합니다.
• 직접 설정합니다 HttpContext.User.

등록된 인증 체계가 하나만 있는 경우 기본 체계가 됩니다. 기본 체계를 지정하지 않은 경우 권한 부여 특성에서 체계를 지정해야 합니다. 그러지 않으면 다음 오류가 스로우됩니다.

InvalidOperationException: authenticationScheme이 지정되지 않았으며 DefaultAuthenticateScheme을 찾을 수 없습니다. 기본 체계는 AddAuthentication(문자열 defaultScheme) 또는 AddAuthentication(Action<AuthenticationOptions> configureOptions)를 사용하여 설정할 수 있습니다.

DefaultScheme

단일 인증 체계만 등록된 경우 단일 인증 체계는 다음과 같습니다.

• DefaultScheme이 자동으로 사용됩니다.
• AddAuthentication(IServiceCollection) 혹은 AddAuthenticationCore(IServiceCollection)에서 DefaultScheme을 명시할 필요가 사라집니다.

자동으로 DefaultScheme을 단일 인증 체계를 사용하는 것을 비활성화하려면 AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme")를 호출합니다.

인증 체계

인증 체계는 올바른 클레임 세트 생성을 담당하는 인증 처리기를 선택할 수 있습니다. 자세한 내용은 특정 체계로 권한 부여를 참조하세요.

인증 체계는 다음에 해당하는 이름입니다.

• 인증 처리기.
• 처리기의 특정 인스턴스를 구성하기 위한 옵션입니다.

체계는 연결된 처리기의 인증, 챌린지 및 금지 동작을 참조하기 위한 메커니즘으로 유용합니다. 예를 들어, 권한 부여 정책은 체계 이름을 사용하여 사용자를 인증하는 데 사용해야 하는 권한 부여 체계(또는 체계)를 지정할 수 있습니다. 인증을 구성할 때 기본 인증 체계를 지정하는 것이 일반적입니다. 리소스에서 특정 체계를 요청하지 않는 한, 기본 체계가 사용됩니다. 또한 다음과 같은 작업을 수행할 수 있습니다.

• 인증, 챌린지 및 금지 작업에 사용할 다른 기본 체계를 지정합니다.
• 정책 체계를 사용하여 여러 스키마를 하나로 결합합니다.

인증 처리기

인증 처리기:

• 체계의 동작을 구현하는 형식입니다.
• IAuthenticationHandler 또는 AuthenticationHandler<TOptions>에서 파생됩니다.
• 사용자를 인증해야 하는 기본 책임이 있습니다.

인증 체계의 구성 및 들어오는 요청 컨텍스트를 기반으로 하는 인증 처리기:

• 인증에 성공하면 사용자 ID를 나타내는 AuthenticationTicket 개체를 생성합니다.
• 인증에 실패하면 '결과 없음' 또는 '실패'를 반환합니다.
• 사용자가 리소스에 액세스하려고 할 때 챌린지 및 금지 작업에 대한 메서드가 있습니다.
  • 액세스 권한이 없습니다(금지).
  • 인증되지 않았습니다(챌린지).

RemoteAuthenticationHandler<TOptions> 및 AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions>은(는) 원격 인증 단계가 필요한 인증을 위한 클래스입니다. 원격 인증 단계가 완료되면 처리기에서 설정한 CallbackPath가 다시 호출됩니다. 처리기는 HandleRemoteAuthenticateAsync 콜백 경로에 전달된 정보를 사용하여 인증 단계를 완료합니다. OAuth 2.0과 OIDC는 모두 이 패턴을 사용합니다. JWT 및 cookie의 경우 전달자 헤더와 cookie를 사용하여 직접 인증할 수 있으므로 이 패턴을 사용하지 않습니다. 이 경우 원격으로 호스트되는 공급자는

• 인증 공급자입니다.
• 예를 들어 Facebook, Twitter, Google, Microsoft, 처리기 메커니즘을 사용하여 사용자 인증을 처리하는 기타 OIDC 공급자가 있습니다.

인증

인증 체계의 인증 작업은 요청 컨텍스트를 기반으로 사용자의 id를 구성합니다. 인증에 성공했는지와 그런 경우 인증 티켓의 사용자 ID를 나타내는 AuthenticateResult을(를) 반환합니다. AuthenticateAsync을(를) 참조하세요. 인증 예는 다음과 같습니다.

• cookie에서 사용자 ID를 생성하는 cookie 인증 체계입니다.
• JWT 전달자 체계는 JWT 전달자 토큰을 역직렬화하고 유효성을 검사하여 사용자 ID를 생성합니다.

과제

인증 챌린지는 인증되지 않은 사용자가 인증을 요구하는 엔드포인트를 요청하는 경우 권한 부여를 수행하여 호출됩니다. 인증 챌린지를 발행합니다(예를 들어, 익명 사용자가 제한된 리소스를 요청하거나 로그인 링크를 따라가는 경우). 권한 부여는 지정된 인증 체계를 사용하여 챌린지를 호출하거나, 기본값(지정되지 않은 경우)을 호출합니다. ChallengeAsync을(를) 참조하세요. 인증 챌린지 예는 다음과 같습니다.

• 사용자를 로그인 페이지로 리디렉션하는 cookie 인증 체계입니다.
• www-authenticate: bearer 헤더를 사용하여 401 결과를 반환하는 JWT 전달자 체계입니다.

챌린지 작업을 통해 요청된 리소스에 액세스하는 데 사용할 인증 메커니즘을 확인할 수 있습니다.

금지

인증된 사용자가 액세스를 허용하지 않는 리소스에 액세스를 시도할 때 인증 체계의 금지 작업이 권한 부여에 의해 호출됩니다. ForbidAsync을(를) 참조하세요. 인증 금지 예는 다음과 같습니다.

• 액세스를 사용할 수 없음을 나타내는 페이지로 리디렉션하는 cookie 인증 체계입니다.
• 403 결과를 반환하는 JWT 전달자 체계입니다.
• 사용자가 리소스에 대한 액세스 권한을 요청할 수 있는 페이지로 리디렉션하는 사용자 지정 인증 체계입니다.

금지 작업을 통해 다음을 확인할 수 있습니다.

• 인증되었습니다.
• 요청된 리소스에 액세스할 수 없습니다.

챌린지와 금지 간의 차이점에 대해서는 다음 링크를 참조하세요.

• 작업 리소스 처리기를 사용하는 챌린지 및 금지
• 챌린지와 금지 간의 차이.

테넌트당 인증 공급자

ASP.NET Core에는 다중 테넌트 인증을 위한 기본 제공 솔루션이 없습니다. 고객이 기본 제공 기능을 사용하여 작성할 수 있지만 고객은 다중 테넌트 인증을 위해 Orchard Core, ABP Framework 또는 Finbuckle.MultiTenant를 고려하는 것이 좋습니다.

Orchard Core는 다음과 같습니다.

• ASP.NET Core로 빌드된 오픈 소스, 모듈형 및 다중 테넌트 앱 프레임워크입니다.
• 해당 앱 프레임워크 위에 빌드된 콘텐츠 관리 시스템(CMS)입니다.

테넌트당 인증 공급자의 예는 Orchard Core 소스를 참조하세요.

ABP Framework는 모듈화, 마이크로 서비스, 도메인 기반 디자인 및 다중 테넌트 등 다양한 아키텍처 패턴을 지원합니다. GitHub에서 ABP Framework 원본을 참조하세요.

Finbuckle.MultiTenant:

• 오픈 소스
• 테넌트 확인 제공
• 간단한 기능
• 데이터 격리 제공
• 각 테넌트에 대해 고유하게 앱 동작 구성

추가 리소스

• ASP.NET Core에서 특정 체계로 권한 부여
• ASP.NET Core의 정책 체계
• 권한 부여로 보호된 사용자 데이터를 사용한 ASP.NET Core 앱 만들기
• 인증된 사용자가 전역적으로 필요함
• 여러 인증 스키마 사용에 대한 GitHub 문제