问题标签 [rfc6749]

看起来 ServiceStack 只接受基于会话的身份验证。我正在阅读https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization，但找不到任何描述如何做我想做的事。

我还查看了http://enehana.nohea.com/general/customizing-iauthprovider-for-servicestack-net-step-by-step/但这也是基于会话的。

我想做的事情与 WebAPI 与个人用户帐户的工作方式非常相似。

我想将此发送到 API：

然后，如果在我的自定义身份验证方法中找到用户，它会返回：

然后，客户端应用程序可以通过将如下值附加到 HTTP 请求来在后续请求中发送 access_token：

这在 ServiceStack 中可行吗？

编辑：使用 .NET 的 WebAPI 实现：http ://www.asp.net/web-api/overview/security/individual-accounts-in-web-api

是什么意思
scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

在RFC6749 3.3 中。访问令牌范围？

我正在开发一个基于rfc6749的 oauth2 提供程序，我想知道，为什么访问令牌请求需要 redirect_uri ？/token 端点没有重定向，并且假定状态已经过验证（即针对 CSRF），因此 redirectURI 的副本对我来说没有多大意义。

我正在阅读oauth2 规范unauthorized_client，但我对access_denied错误代码感到困惑。它们似乎表达了相同的错误条件，不是吗？乍一看（通过错误代码），我认为一个是身份验证失败，另一个是授权失败，但它们实际上都是关于授权失败，这将转换为 http 403 状态代码。

背景

我正在构建一个水疗中心和移动应用程序，它将与一个休息 api 进行通信。我想运行一个单独的身份验证服务器来管理用户（资源所有者），并认为 oAuth2 4.3 资源所有者密码凭据授予对我的应用程序有意义。

如规范中所述，用户（资源所有者）应该直接与我的 rest api（客户端）通信，然后我的 rest api（客户端）应该与身份验证服务器通信。

但是，我想改变这个流程。我希望用户（资源所有者）直接与身份验证服务器通信，接收令牌，然后使用这些令牌与我的 rest api（客户端）进行通信：

仅供参考，步骤 (E) 和 (F) 如RFC 7662中所定义。

问题

我想知道你对这个设计有什么想法。我知道这是 RFC 6749 的混蛋，但我认为它更适合我的需求。

1. 是否有 RFC 6749 中定义的更好的流程可以满足我的需求？
2. 除了 RFC 6749 之外，还有其他规范可以更好地满足我的需求吗？

我认为我的流程的优点是：

• 不需要我在水疗中心或移动应用程序中存储密码
• 允许我的用户直接与身份验证服务器通信以进行登录/注销等。将关注点与我的其余 api(s) 完全分离
• 允许我更轻松地添加其他 api（微服务），而无需处理用户身份验证。

我认为缺点是：

• 要求我的身份验证服务器面向公众
• 需要更多步骤
• 完全不符合规范

我正在编写一个 OAuth 2.0 客户端应用程序，并且我正在尝试使用ImplicitAccessTokenProvider. /oauth/token但问题是这个类允许通过向授权服务器的端点发送 POST 请求来请求访问令牌。

为了让我的授权服务器支持这种不同的隐式流实现，我应该将授权服务器更改为支持隐式授予类型以通过/oauth/token. 但它违反了 RFC 6749，因为必须隐式检索访问令牌以响应资源所有者的授权。

有没有人写过任何依赖于ImplicitAccessTokenProvider分享经验的客户端应用程序？

Oauth2 的 RFC 说redirect_uri生成授权代码时指定的内容必须包含在请求中以交换访问令牌的代码。

来自 RFC：

4.1.3。访问令牌请求

客户端通过使用附录 B 中的“application/x-www-form-urlencoded”格式发送以下参数向令牌端点发出请求，HTTP 请求实体主体中的字符编码为 UTF-8：

[...]

重定向uri

要求，如果“redirect_uri”参数包含在第 4.1.1 节中描述的授权请求中，并且它们的值必须相同。

https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3

为什么redirect_uri在交换访问令牌的代码时需要？这有什么好处？

诸如此Okta 赞助网站之类的来源（请参阅“按请求自定义”部分）提到，自动化请求的 redirect_uri 参数不应具有动态查询部分（例如：用于会话匹配用途）。

引用：

服务器应拒绝任何带有与已注册 URL 不完全匹配的重定向 URL 的授权请求。

我们的 OAuth AZ 提供商是 BIG-IP F5。我们正在设置它，它们似乎符合上述观点。

我们的客户端是在别处构建的 Web 应用程序，它们似乎没有遵循上述规则。这是授权端点的完整表示（已编辑）： https ://ourownF5host.ca/f5-oauth2/v1/authorize?client_id=theIDofOurClient&redirect_uri=https%3A%2F%2FourClientAppHostname%2FClientRessource%2FRessource%3FSessionId%3D76eab448-52d1 -4adb-8eba-e9ec1b9432a3&state=2HY-MLB0ST34wQUPCyHM-A&scope=RessourceData&response_type=code

他们使用的 redirect_uri 格式类似于（为简单起见，我在这里不进行 urlencode）：redirect_uri= https://ourClientAppHostname/ClientRessource/Ressource?SessionId=SOMELONGSESSIONID，每次调用的 SOMELONGSESSIONID 值都不同。

我们深入研究了RFC6749 (OAuth2)，并在第 3.1.2.2 节中找到了这一点：

授权服务器应该要求客户端提供
完整的重定向 URI（客户端可以使用“state”请求
参数来实现每个请求的定制）。如果要求
注册完整的重定向 URI 是不可能的，
授权服务器应该要求注册 URI
方案、权限和路径（允许客户端
在请求
授权时仅动态更改重定向 URI 的查询组件）。

我理解并想在此验证的是，第一个来源 Okta 和 F5 仅接受上述规则的第一部分，并要求重定向 uri 完全注册而没有任何动态部分。

我是否可以肯定他们（Okta 和 F5）不遵守摘录的第二部分，理由是他们应该“允许（ing）客户端在请求授权时仅动态更改重定向 URI 的查询组件”？

或者，RFC6749 是否有任何形式的官方更正/演变，以保证两家公司的设计立场？

我有一个符合 OAuth2.0 和 RFC 6749 的应用程序。

我现在需要扩展行为，以便新的 RP 将调用我的/auth端点，并且它期待包含我的 auth_ref 的响应，因此我认为我应该在请求中application/x-www-form-urlencoded使用而不是默认格式。application/json这有两个原因：

1. 如果请求来自 Web 浏览器，我不需要使用登录页面响应更改我现有的 http Web 重定向行为
2. 我可以扩展系统以迎合新的 RP，该 RP 需要包含 auth_ref 的 JSON 响应等

Q1。这个规范符合吗？根据我对RFC的理解

Q2。我正在考虑的另一种方法是只公开一个不同的端点/authz

Q3。还要考虑在同一/auth端点上向请求添加新参数的可能性。这也会变得不符合规范吗？还是将其视为规范的扩展？如果我扩展它有什么影响吗？

提前致谢。

我正在阅读 OAuth 2.0 RFC 6749。在部分：（协议端点）[https://www.rfc-editor.org/rfc/rfc6749#section-3] 中提到授权服务器需要一个authorization endpoint. 在我正在构建的应用程序中，需要另一个想要以不同方式完成授权代码流的客户端，因此考虑了两个选项：

1. 在不同的路径上公开一个新端点

2. 保留现有端点 ( /authorization) 但注意新客户端将提供的标头

该规范没有说明公开多个授权端点。想知道它是否合规？