3

我想使用 DotNetOpenAuth 从一个具有 DotNetOpenAuth 的站点连接到另一个具有 DotNetOpenAuth 的站点，以便他们可以使用彼此的 api。目标是必须授权一次，从那时起他们可以在彼此之间做事。它们必须是两个不同的站点，都是 C# 城堡项目。老实说，其中大约有 5 个需要相互交谈并使用彼此的 api，所以我只想存储一次连接，而不用担心它们断开连接。我设置了数据库来存储我相信的会话和令牌，但事实证明，DotNetOpenAuth 的文档没有那么有用。 （在撰写DotNetOpenAuth api 文档的网站时已关闭）我不清楚这个web.config设置是我需要做的所有事情，这对我来说似乎很奇怪，或者如果有一些示例可以逐步说明我所询问的内容。

它的核心问题很简单，你如何设置一个站点来授权另一个站点并且只存储一次。我的想法是我不知道这些微站点最终会有多少，只是他们必须建立双向授权连接，然后使用彼此的api。

我所需要的只是一个为 Web 应用程序设置的提供程序和一个为 Web 应用程序设置的客户端的详细示例。我敢肯定他们不会出现在同一个例子中，但我很难找到任何一步一步明确的东西。少数令人费解的示例是 MVC 示例，它们无助于轻松了解其核心。

最终目标是（站点 A）与（站点 B）和（站点 C）有连接，其中（站点 C）与（站点 A）和（站点 D）有连接，这意味着（站点 A），（站点 B ),(Site C),(Site D) 既是提供者又是客户端，我们通常会将令牌存储在数据库中的会话中（从客户端的角度来看）。不需要更多的例子来说明如何清楚地制作提供者以及如何制作客户端，因为其余部分在存储时会很明显。

更新 我一直在尝试整合这个例子，因为它是我能找到的最好的一个。问题在于，它更像是一个应用程序的提供者，而不是一个包含提供者和消费者的网站。该示例的问题在于它并没有真正与文件对齐​​。它轻而易举地解决了关键部分的想法。

可视化概念

在此处输入图像描述

4

2 回答 2

2

您可以将其用作AuthorisationServer实现的基础，并在所有 API 解决方案中共享该库。

您提到的集中式解决方案可能是一个不错的计划，具体取决于您希望如何构建各种 API 实现的整体架构。真的很难在这方面提出任何建议，因为这实际上取决于您希望它们如何结合在一起。

如果您采用集中式方法，则必须为每个 API 提供一个密钥和一个秘密，并在数据库的 ClientAuthorisation 表中为每个 API 创建一个条目。我的授权表现在看起来像这样：

CREATE TABLE [dbo].[ApiClientAuthorizations](
    [Id] [bigint] IDENTITY(1,1) NOT NULL,
    [CreatedUtc] [datetime] NOT NULL,
    [ApiClientId] [bigint] NOT NULL,
    [UserProfileId] [bigint] NOT NULL,
    [Scope] [nvarchar](max) NULL,
    [Expires] [datetime] NULL,

这里的关键字段是定义任何客户端访问级别的范围。据我所知，如果您真的想开始让其他系统使用您的实现来使用您的系统作为他们的身份存储来保护他们自己的服务，那么您只需要实现一个提供程序，我真的认为您不需要这样做为了满足您对此的要求。

我发现让大量示例实际工作非常耗时，但示例中的代码确实非常好，值得仔细研究以更好地了解引擎盖下的实际情况。

于 2013-04-26T17:24:30.380 回答
1

您实际上并不需要成为提供者来实现这一点。我将对授权服务器进行通用实现，并在数据库中为您希望在每台服务器上与之通信的每个站点手动设置授权。

使用 SSL 证书进行加密，您最好使用发送 OAuth2.0 令牌来授权 API 调用。

于 2013-04-26T12:56:58.643 回答