C#中认证和授权有什么区别？ASP.NET Core里Authentication和Authorization的流程是怎样的

来源：微信开发网作者：广州GEO公司头衔：草根站长
导读：本期聚焦于小伙伴创作的《C#中认证和授权有什么区别？ASP.NET Core里Authentication和Authorization的流程是怎样的》，敬请观看详情，探索知识的价值。以下视频、文章将为您系统阐述其核心内容与价值。如果您觉得《C#中认证和授权有什么区别？ASP.NET Core里Authentication和Authorization的流程是怎样的》有用，将其分享出去将是对创作者最好的鼓励。

在ASP.NET Core的安全体系中，认证（Authentication）和授权（Authorization）是保障系统资源安全的两道核心防线，二者作用不同但相互配合，很多开发者在初学时容易将两者混淆。要理解它们的区别，首先需要明确各自的核心定位，再结合框架的执行流程梳理实际的工作逻辑。

C#中认证和授权有什么区别？ASP.NET Core里Authentication和Authorization的流程是怎样的

认证和授权的核心区别

认证和授权的本质差异体现在作用阶段和目标上，具体可以从以下几个维度区分：

  • 核心目标不同：认证的目标是验证用户身份的合法性，回答“你是谁”的问题；授权的目标是验证用户权限的合法性，回答“你能做什么”的问题。
  • 执行顺序不同：在请求处理流程中，认证一定先于授权执行，只有先确认了用户身份，才能进一步判断该用户的权限范围。
  • 依赖关系不同：授权依赖认证的结果，没有合法的身份信息，授权环节无法判断当前用户的权限归属；而认证不需要依赖授权，即使没有配置授权规则，认证流程也可以独立运行。
  • 失败表现不同：认证失败时，系统通常会返回401未授权状态码，提示用户需要重新登录；授权失败时，系统通常会返回403禁止访问状态码，提示用户没有操作权限。

ASP.NET Core中认证（Authentication）的流程

ASP.NET Core的认证流程是通过认证中间件和认证服务配合完成的，整体可以分为配置、触发、处理三个阶段。

1. 认证服务的配置

首先需要在Program.cs中注册认证服务，并配置具体的认证方案，常用的有Cookie认证、JWT Bearer认证等，以下是Cookie认证的配置示例：

// Program.cs 中配置认证服务
var builder = WebApplication.CreateBuilder(args);

// 添加认证服务，配置Cookie认证方案
builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        // 登录路径，未认证时跳转到该地址
        options.LoginPath = "/Account/Login";
        // 认证过期时间
        options.ExpireTimeSpan = TimeSpan.FromHours(2);
        // 访问被拒绝时的跳转路径
        options.AccessDeniedPath = "/Account/AccessDenied";
    });

var app = builder.Build();

// 启用认证中间件，注意顺序要在授权中间件之前
app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();
app.Run();

2. 认证流程的触发

当用户发起登录请求时，服务端验证用户凭证（比如用户名密码）通过后，会创建用户的身份标识并颁发认证票据，以下是登录逻辑的实现示例：

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.Authentication.Cookies;
using System.Security.Claims;

[HttpPost("/Account/Login")]
public async Task<IActionResult> Login(string username, string password)
{
    // 模拟验证用户名密码的逻辑
    if (username == "admin" && password == "123456")
    {
        // 创建用户声明，存储用户基本信息
        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.Name, username),
            new Claim(ClaimTypes.Role, "Admin")
        };
        // 创建身份标识
        var claimsIdentity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
        // 登录，颁发Cookie票据
        await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(claimsIdentity));
        return Redirect("/Home/Index");
    }
    return Content("用户名或密码错误");
}

3. 认证流程的完整链路

当用户携带认证票据（比如Cookie）发起后续请求时，认证流程如下：

  1. 请求到达认证中间件，中间件从请求中提取认证票据。
  2. 验证票据的合法性，包括是否过期、签名是否正确等。
  3. 如果票据合法，解析票据中的用户信息，创建ClaimsPrincipal对象，附加到当前请求的HttpContext.User属性上。
  4. 如果票据不合法或者不存在，HttpContext.User会被设置为未认证的匿名用户对象。

ASP.NET Core中授权（Authorization）的流程

授权流程是在认证完成之后执行的，依赖认证环节生成的用户身份信息进行权限判断，同样需要先配置授权服务，再在资源上应用授权规则。

1. 授权服务的配置

授权服务可以和认证服务一起注册，支持配置基于角色、基于策略等多种授权规则，以下是基础配置示例：

// Program.cs 中配置授权服务
var builder = WebApplication.CreateBuilder(args);

// 添加授权服务
builder.Services.AddAuthorization(options =>
{
    // 定义一个名为AdminOnly的策略，要求用户拥有Admin角色
    options.AddPolicy("AdminOnly", policy => policy.RequireRole("Admin"));
});

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();
app.Run();

2. 授权规则的应用

配置好授权规则后，可以通过特性或者代码的方式将规则应用到控制器或者接口上，以下是两种常用的应用方式：

基于特性的授权

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class OrderController : ControllerBase
{
    // 要求用户必须认证才能访问该接口
    [Authorize]
    [HttpGet("list")]
    public IActionResult GetOrderList()
    {
        return Ok("订单列表数据");
    }

    // 要求用户拥有Admin角色才能访问该接口
    [Authorize(Roles = "Admin")]
    [HttpPost("delete")]
    public IActionResult DeleteOrder(int orderId)
    {
        return Ok($"订单{orderId}删除成功");
    }

    // 应用自定义的AdminOnly策略
    [Authorize(Policy = "AdminOnly")]
    [HttpPut("update")]
    public IActionResult UpdateOrder(int orderId)
    {
        return Ok($"订单{orderId}更新成功");
    }
}

基于代码的授权

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class ProductController : ControllerBase
{
    private readonly IAuthorizationService _authorizationService;

    public ProductController(IAuthorizationService authorizationService)
    {
        _authorizationService = authorizationService;
    }

    [HttpGet("detail")]
    public async Task<IActionResult> GetProductDetail()
    {
        // 代码判断当前用户是否满足Admin角色要求
        var authorizationResult = await _authorizationService.AuthorizeAsync(User, "Admin");
        if (authorizationResult.Succeeded)
        {
            return Ok("产品详情数据");
        }
        else
        {
            return Forbid();
        }
    }
}

3. 授权流程的完整链路

当请求经过认证中间件处理之后，进入授权环节时，流程如下：

  1. 请求到达授权中间件，中间件检查当前请求对应的资源是否配置了授权规则。
  2. 如果没有配置授权规则，直接允许请求继续执行。
  3. 如果配置了授权规则，提取当前HttpContext.User中的用户身份信息，和授权规则进行匹配。
  4. 如果用户满足授权规则要求，允许请求继续执行；如果不满足，返回403禁止访问状态码，如果用户未认证则返回401未授权状态码。

实际开发中的注意事项

  • 认证和授权中间件的注册顺序不能颠倒，必须先注册UseAuthentication再注册UseAuthorization，否则授权环节无法获取到正确的用户身份信息。
  • 认证方案的选择需要和前端的交互方式匹配，比如前后端分离项目通常使用JWT Bearer认证，传统Web项目更适合Cookie认证。
  • 授权规则尽量基于策略配置，而不是硬编码角色名称，这样可以提高规则的复用性和灵活性，后续调整权限时不需要修改业务代码。
  • 敏感操作一定要同时做认证和授权校验，避免出现未登录用户或者低权限用户访问高权限接口的安全问题。

AuthenticationAuthorizationASP.NET_CoreC#修改时间：2026-06-16 17:45:26

免责声明：​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰，观点力求客观中立。本站旨在免费分享，内容仅供个人学习、研究或参考使用。若引用了第三方作品，版权归原作者所有。如内容涉及您的权益，请联系我们处理。

上一篇C#如何在高并发下保证Redis操作的原子性 Lua脚本和事务

下一篇c语言switch怎么用

猜你喜欢

内容垂直聚焦
专注技术核心技术栏目，确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计，为用户提供无干扰的纯技术知识沉淀，精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进，构建清晰学习路径，帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈，深入技术细节与实践难点。无论是数据库优化还是服务器配置，均结合真实场景与代码示例进行剖析，致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程，从数据库操作到服务器运维，形成完整闭环，一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性，步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目，显著缩短从学习到实践的距离，快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代，紧跟主流技术发展趋势，为用户提供经久不衰的学习价值。

负责任网站 - 免责声明 - 隐私政策 - 网站地图

举报邮箱：chomcom@qq.com

Copyright (C) www.ipipp.com All Rights Reserved.