다음을 통해 공유

ASP.NET Core 인증 개요

By Mike Rousos

인증은 사용자의 ID를 결정하는 프로세스입니다. Authorization은 사용자가 리소스에 access 있는지 여부를 결정하는 프로세스입니다. ASP.NET Core 인증은 인증 서비스인 IAuthenticationService 의해 처리되며, 인증 middleware에서 사용됩니다. 인증 서비스는 등록된 인증 처리기를 사용하여 인증 관련 작업을 완료합니다. 인증 관련 작업의 예는 다음과 같습니다.

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

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

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

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

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

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

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

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

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

인증 미들웨어는 에서 을 호출하여 추가됩니다. 을 호출하면 이전에 등록된 인증 체계를 사용하는 미들웨어가 등록됩니다. 중간웨어가 인증된 사용자에 의존하기 전에 을(를) 호출합니다.

인증 개념

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

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

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

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

DefaultScheme

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

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

자동으로 을 단일 인증 체계를 사용하는 것을 비활성화하려면 를 호출합니다.

인증 체계

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

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

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

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

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

인증 처리기

인증 처리기:

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

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

  • 인증에 성공하면 사용자의 ID를 나타내는 개체를 생성 합니다.
  • 인증에 실패하면 '결과 없음' 또는 '실패'를 반환합니다.
  • 사용자가 리소스에 접근을 시도할 때 인증 및 차단 작업을 위한 메서드를 갖추고 있습니다.
    • 접근 권한이 없습니다(금지됨).
    • 인증되지 않았습니다(챌린지).

및

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

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

인증

인증 체계의 인증 작업은 요청 컨텍스트에 따라 사용자의 ID를 생성하는 역할을 합니다. 인증이 성공했는지 여부와 인증 티켓의 사용자 ID를 나타내는 값을 반환합니다. 을(를) 참조하세요. 인증 예는 다음과 같습니다.

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

과제

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

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

챌린지 작업은 요청된 리소스를 access 데 사용할 인증 메커니즘을 사용자에게 알려야 합니다.

금지

인증된 사용자가 access 수 없는 리소스를 access 시도하면 인증 체계의 금지 동작이 Authorization에 의해 호출됩니다. 을(를) 참조하세요. 인증 금지 예는 다음과 같습니다.

  • 사용자를 접근이 금지되었음을 나타내는 페이지로 리디렉션하는 cookie 인증 체계입니다.
  • 403 결과를 반환하는 JWT 베어러 스키마입니다.
  • 사용자가 리소스에 대한 access 요청할 수 있는 페이지로 리디렉션되는 사용자 지정 인증 체계입니다.

사용자가 금지된 작업을 알 수 있습니다.

  • 인증되었습니다.
  • 요청된 리소스를 access 수 없습니다.

도전과 금지의 차이점을 보려면 다음 링크를 참조하세요.

  • 운영 자원 처리기를 사용하여 도전하고 금지하십시오
  • 챌린지와 금지 간의 차이.

테넌트당 인증 공급자

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

Orchard Core는 다음과 같습니다.

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

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

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

Finbuckle.MultiTenant:

  • 오픈 소스
  • 테넌트 해결 제공
  • 경량의
  • 데이터 격리를 제공합니다
  • 각 테넌트에 대해 고유하게 앱 동작 구성

추가 리소스

By Mike Rousos

인증은 사용자의 ID를 결정하는 프로세스입니다. Authorization은 사용자가 리소스에 access 있는지 여부를 결정하는 프로세스입니다. ASP.NET Core 인증은 인증 서비스인 IAuthenticationService 의해 처리되며, 인증 middleware에서 사용됩니다. 인증 서비스는 등록된 인증 처리기를 사용하여 인증 관련 작업을 완료합니다. 인증 관련 작업의 예는 다음과 같습니다.

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

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

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

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

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

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

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

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

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

인증 미들웨어는 에서 을 호출하여 추가됩니다. 을 호출하면 이전에 등록된 인증 체계를 사용하는 미들웨어가 등록됩니다. 중간웨어가 인증된 사용자에 의존하기 전에 을(를) 호출합니다.

인증 개념

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

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

체계는 자동으로 탐색되지 않습니다. 기본 체계를 지정하지 않은 경우 권한 부여 특성에서 체계를 지정해야 합니다. 그러지 않으면 다음 오류가 throw됩니다.

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

인증 체계

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

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

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

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

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

인증 처리기

인증 처리기:

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

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

  • 인증에 성공하면 사용자의 ID를 나타내는 개체를 생성 합니다.
  • 인증에 실패하면 '결과 없음' 또는 '실패'를 반환합니다.
  • 사용자가 리소스에 접근을 시도할 때 인증 및 차단 작업을 위한 메서드를 갖추고 있습니다.
    • 접근 권한이 없습니다(금지됨).
    • 인증되지 않았습니다(챌린지).

및

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

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

인증

인증 체계의 인증 작업은 요청 컨텍스트에 따라 사용자의 ID를 생성하는 역할을 합니다. 인증이 성공했는지 여부와 인증 티켓의 사용자 ID를 나타내는 값을 반환합니다. 을(를) 참조하세요. 인증 예는 다음과 같습니다.

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

과제

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

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

챌린지 작업은 요청된 리소스를 access 데 사용할 인증 메커니즘을 사용자에게 알려야 합니다.

금지

인증된 사용자가 access 수 없는 리소스를 access 시도하면 인증 체계의 금지 동작이 Authorization에 의해 호출됩니다. 을(를) 참조하세요. 인증 금지 예는 다음과 같습니다.

  • 사용자를 접근이 금지되었음을 나타내는 페이지로 리디렉션하는 cookie 인증 체계입니다.
  • 403 결과를 반환하는 JWT 베어러 스키마입니다.
  • 사용자가 리소스에 대한 access 요청할 수 있는 페이지로 리디렉션되는 사용자 지정 인증 체계입니다.

사용자가 금지된 작업을 알 수 있습니다.

  • 인증되었습니다.
  • 요청된 리소스를 access 수 없습니다.

도전과 금지의 차이점을 보려면 다음 링크를 참조하세요.

  • 운영 자원 처리기를 사용하여 도전하고 금지하십시오
  • 챌린지와 금지 간의 차이.

테넌트당 인증 공급자

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

Orchard Core는 다음과 같습니다.

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

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

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

추가 리소스

By Mike Rousos

인증은 사용자의 ID를 결정하는 프로세스입니다. Authorization은 사용자가 리소스에 access 있는지 여부를 결정하는 프로세스입니다. ASP.NET Core 인증은 인증 서비스인 IAuthenticationService 의해 처리되며, 인증 middleware에서 사용됩니다. 인증 서비스는 등록된 인증 처리기를 사용하여 인증 관련 작업을 완료합니다. 인증 관련 작업의 예는 다음과 같습니다.

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

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

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

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

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

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

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

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

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

인증 미들웨어는 에서 을 호출하여 추가됩니다. 을 호출하면 이전에 등록된 인증 체계를 사용하는 미들웨어가 등록됩니다. 중간웨어가 인증된 사용자에 의존하기 전에 을(를) 호출합니다. 엔드포인트 라우팅을 사용하는 경우 에 대한 호출이 다음과 같이 이동해야 합니다.

  • 후에 인증 결정을 위해 경로 정보를 사용할 수 있습니다.
  • 사용자가 엔드포인트에 액세스하기 전에 를 먼저 수행하여 인증을 완료합니다.

인증 개념

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

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

체계는 자동으로 탐색되지 않습니다. 기본 체계를 지정하지 않은 경우 권한 부여 특성에서 체계를 지정해야 합니다. 그러지 않으면 다음 오류가 throw됩니다.

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

인증 체계

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

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

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

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

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

인증 처리기

인증 처리기:

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

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

  • 인증에 성공하면 사용자의 ID를 나타내는 개체를 생성 합니다.
  • 인증에 실패하면 '결과 없음' 또는 '실패'를 반환합니다.
  • 사용자가 리소스에 접근을 시도할 때 인증 및 차단 작업을 위한 메서드를 갖추고 있습니다.
    • 접근 권한이 없습니다(금지됨).
    • 인증되지 않았습니다(챌린지).

및

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

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

인증

인증 체계의 인증 작업은 요청 컨텍스트에 따라 사용자의 ID를 생성하는 역할을 합니다. 인증이 성공했는지 여부와 인증 티켓의 사용자 ID를 나타내는 값을 반환합니다. 을(를) 참조하세요. 인증 예는 다음과 같습니다.

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

과제

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

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

챌린지 작업은 요청된 리소스를 access 데 사용할 인증 메커니즘을 사용자에게 알려야 합니다.

금지

인증된 사용자가 access 수 없는 리소스를 access 시도하면 인증 체계의 금지 동작이 Authorization에 의해 호출됩니다. 을(를) 참조하세요. 인증 금지 예는 다음과 같습니다.

  • 사용자를 접근이 금지되었음을 나타내는 페이지로 리디렉션하는 cookie 인증 체계입니다.
  • 403 결과를 반환하는 JWT 베어러 스키마입니다.
  • 사용자가 리소스에 대한 access 요청할 수 있는 페이지로 리디렉션되는 사용자 지정 인증 체계입니다.

사용자가 금지된 작업을 알 수 있습니다.

  • 인증되었습니다.
  • 요청된 리소스를 access 수 없습니다.

도전과 금지의 차이점을 보려면 다음 링크를 참조하세요.

  • 운영 자원 처리기를 사용하여 도전하고 금지하십시오
  • 챌린지와 금지 간의 차이.

테넌트당 인증 공급자

ASP.NET Core 프레임워크에는 다중 테넌트 인증을 위한 기본 제공 솔루션이 없습니다. 고객이 다중 테넌트 인증을 사용하여 앱을 작성할 수 있지만 다중 테넌트 인증을 지원하는 다음 ASP.NET Core 애플리케이션 프레임워크 중 하나를 사용하는 것이 좋습니다.

Orchard Core CMS(콘텐츠 관리 시스템)를 제공하는 ASP.NET Core 사용하여 빌드된 오픈 소스, 모듈식 및 다중 테넌트 앱 프레임워크입니다. 테넌트당 인증 공급자의 예는 Orchard Core 소스를 참조하세요.

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

추가 리소스

  • Last updated on