ASP.NET Core MVC EF身份体系对接MAUI统一授权方案咨询

DevOps 小满

2026-8-26

最佳实践结论

针对你现有已经稳定运行的ASP.NET Core MVC + Identity技术栈，优先选择扩展现有Identity体系支持移动端Token授权的方案（即你列出的第一个方案的标准化实现），完全保留现有Web端身份逻辑、用户数据零迁移，改造成本最低、故障风险最小，是同技术栈跨端场景的业界通用落地方式。Azure AD、第三方IdP方案仅在满足特定业务需求时才值得选型，不要为了“用新技术”盲目全量迁移。

具体落地步骤（无侵入兼容现有系统）

全程不需要修改现有Identity用户表、角色表结构，不需要改动现有MVC端的Cookie登录、权限校验逻辑，所有新增逻辑和原有逻辑并行运行：

首先在认证服务注册环节，保留原有MVC端用的Cookie认证配置，并行新增JWT Bearer认证支持，两套认证方案互不干扰，核心注册代码参考：

builder.Services.AddAuthentication()
    // 原有MVC端的Cookie认证配置完全保留，一行不用改
    .AddCookie(options => {
        options.LoginPath = "/Account/Login";
        // 其余你之前写的Cookie配置全不动
    })
    // 新增给MAUI移动端API用的JWT认证
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]))
        };
    });

新增专供MAUI端调用的身份相关API，所有身份校验逻辑完全复用Identity内置的UserManager、SignInManager类，不要自己重写密码校验、用户查询逻辑：
- 登录接口：接收移动端传入的账号密码，调用SignInManager.PasswordSignInAsync完成账号密码、二次校验、账号锁定状态等校验，校验通过后签发30分钟有效期的Access Token，以及7天有效期的Refresh Token；Refresh Token存在现有数据库的新增关联表中，和对应用户ID绑定，支持吊销。
- 注册接口：直接复用现有Web端的注册校验规则（密码强度、手机号/邮箱验证、用户重复校验等），注册完成后不签发Cookie，直接返回和登录接口一致的Token结构即可。
- Token刷新接口：接收客户端传入的Refresh Token，校验有效性、是否过期、是否被吊销后，重新签发新的Access Token，校验失败直接返回401状态码。
给所有供MAUI调用的CRUD API接口单独标记授权方案，原有MVC控制器的授权逻辑完全不需要调整：

// MAUI专用API用JWT授权
[ApiController]
[Route("api/maui/[controller]")]
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
public class MauiDataController : ControllerBase
{
    // 你的CRUD逻辑
}

// 原有MVC控制器保持原有[Authorize]标记不变，默认走Cookie认证

MAUI端实现统一的HTTP请求拦截器：用SecureStorage加密存储Access Token和Refresh Token，发起API请求时自动把Access Token放到请求头的Authorization字段中；如果收到401响应，自动调用Refresh Token接口换发新的Access Token重试请求，刷新失败则跳转移动端登录页。

其余两个备选方案的适用边界

不要上来就选型，只有匹配对应场景再考虑，且绝对不要做一次性全量用户迁移：

Azure AD方案：仅在你全栈深度绑定Azure云服务、需要对接企业域账号/Office 365账号体系、团队有成熟的Azure运维能力时选择。落地时优先用Azure AD B2C做联邦身份关联，把现有Identity账号作为本地IdP对接，不要直接清空现有用户库全量迁移，否则会导致所有老用户必须重置密码，引发线上故障。
Okta/OneLogin等第三方IdP方案：仅在你需要对接多套异构业务系统、有强合规要求（金融、医疗等行业的多因素认证、操作审计、等保合规需求）、能承担持续的商业授权成本时选择。落地时用JIT（即时迁移）策略，老用户第一次用原有账号密码在第三方IdP登录时再同步用户数据，不要一次性割接。

落地避坑提醒

不要图省事给MAUI端复用Cookie认证：移动端对Cookie的存储、跨域、续期支持很差，后续适配iOS/安卓的网络安全策略会出大量兼容性问题，JWT是移动端API授权的标准选型。
不要自己实现密码哈希、权限校验逻辑：所有身份相关操作全走Identity内置的Manager类，避免出现密码存储不符合安全规范、权限校验漏判的低级安全问题。
JWT签名密钥必须存在环境变量或者专用配置服务中，绝对不要硬编码在代码里；Refresh Token必须做服务端存储和吊销逻辑，不能只在客户端存储不做服务端校验，否则出现Token泄露无法止损。

内容的提问来源于stack exchange，提问作者user2764325