实验性替代流程：OAuth第一方应用程序

本文探讨了一种实现原生应用身份验证与授权的替代方法。目前，在使用OAuth和OpenID Connect时，原生应用通常通过Web浏览器完成身份验证。本文实现的替代方案基于《OAuth 2.0第一方应用程序》草案，并调整为以设备/应用为中心。其目标是先认证设备，然后将用户绑定到设备，确保安全通道无漏洞。强制性的防钓鱼认证可以作为设备的原生实现，这是业务的责任。

一个可用的实验性概念验证可以在这里找到：代码：https://github.com/damienbod/OAuthClientAssertionsPerInstance

该示例使用Duende IdentityServer实现流程，并使用控制台应用程序实现原生应用。

描述

主要理念：设备上的应用程序可以先进行认证，然后将用户附加到应用程序。

设备将使用私钥/公钥对，服务器将为"公钥"创建并附加一个"auth_session"。需要对客户端断言进行调整。从此时起，可以使用使用客户端断言请求令牌的OAuth客户端凭据流程。所有访问令牌都将包含auth_session，并可以使用它来实现进一步的授权。

一旦设备可以请求访问令牌，用户属性可以根据需要附加到此安全实例。业务应用程序可以在此之后决定用户授权级别。

优势（与当前草案相比）

应用程序/设备首先被认证且是唯一的。
auth_session值与应用程序/设备的绑定确保auth_session引用的上下文不能被窃取并在其他设备上重用。
用户注册可以以应用程序特定的方式实现，并使用现有的OAuth标准进行注册。端点不需要安全更改。（使用令牌中包含auth_session声明的OAuth客户端凭据令牌。）
设备负责用户注册，结果可以根据业务需求附加到服务器设备会话。
不需要刷新令牌，但可以使用。
用户恢复过程可以以业务特定的方式实现。不属于安全规范的一部分。

劣势

需要在现有实现中调整客户端断言。
应用程序访问令牌中包含的auth_session必须附加到客户端断言请求中。无漏洞。
初始会话设置端点不安全，容易受到DDoS攻击。

流程

流程可能如下所示：

图：第一方客户端授权设备请求

(A) 第一方客户端首次启动应用程序并创建非对称私钥、公钥对。客户端通过使用公钥向设备注册端点发出POST请求来启动授权请求。

(B) 授权服务器确定提供给设备注册端点的信息是否足够。服务器为公钥创建’auth_session’，并在响应中返回’auth_session’。

(C) 设备使用客户端断言和使用私钥创建的OAuth客户端凭据请求访问令牌。‘auth_session’通过’device_auth_session’声明添加到客户端断言中。附加到auth_session的公钥用于验证客户端断言。可选地，使用DPoP请求令牌。DPoP不使用相同的私钥、公钥对。

(D) 授权服务器从令牌端点返回访问令牌。‘auth_session’在访问令牌中返回。

(E) 授权挑战端点用于将用户身份验证属性附加到设备和auth_session。授权服务器使用标准OAuth要求（包括DPoP）授权访问令牌。auth_session声明用于为用户授权特定内容。

(F) .. (G) 对n个用户属性重复 (H) ..

流程详情

流程详情可以在这里找到： https://github.com/damienbod/OAuthClientAssertionsPerInstance/blob/main/OAuth_first_party_adapted_draft.md

OAuth第一方应用程序实验性替代流程解析

本文探讨了一种原生应用身份验证与授权的替代实现方案，基于OAuth 2.0第一方应用程序草案，通过设备公私钥对和auth_session机制实现安全通道的无缝用户绑定，包含完整流程说明和优缺点分析。

实验性替代流程：OAuth第一方应用程序

描述

优势（与当前草案相比）

劣势

流程

流程详情

链接

规范