1

太多的间接层，这让我很困惑。

在正常的 OAuth 中，最后一站通常需要使用稍后将通过公钥解密的授权令牌发回依赖方（又名服务器）。

到目前为止，我看到的唯一示例是：

String FacebookURL = "https://www.facebook.com/dialog/oauth?client_id=" + FacebookClientID.Text + "&redirect_uri=" + Uri.EscapeUriString(FacebookCallbackUrl.Text) + "&scope=read_stream&display=popup&response_type=token";

但是，经纪人似乎能够确定用户是否合法而无需访问您自己的服务器。如以下行所示：

if (WebAuthenticationResult.ResponseStatus == WebAuthenticationStatus.Success)

那怎么安全？

  1. 服务器不应该进行解密吗？
  2. 就此而言，您的服务器不应该启动连接吗？通过这种方式，它可以向 salt 发送一些随机位，以便 facebook 可以保护返回令牌？

那么重定向 URI 是否完全任意，代理本质上是解析来自 IP（身份提供者）的响应。

是否有一些第三方服务器参与该过程，例如。MS自己的服务器使这成为可能，我不知道？

如果重定向 URI 应该是指向我自己的服务的 URI，那么我该如何处理和响应请求呢？

4

1 回答 1

4

这WebAuthenticationBroker只是在身份验证完成时自动查找要导航到的特定 URL 并取消它以提取access_token. 这主要用于具有嵌入式浏览器的移动应用程序。不涉及服务器（授权服务器除外）。

OAuth2 中有两种常用的身份验证流程：

  1. 授权码流程
  2. 隐式授权流程

在#1 中，您有 3 个部分：您的服务器、授权服务器（例如 Facebook）和浏览器。在这个流程中，access_token 在你的服务器和 AS 之间协商，浏览器是一个中介。（更多细节在这篇文章中有描述）

在 #2 中access_token，浏览器（或嵌入在本机应用程序中的浏览器）和 AS 之间直接协商。任何地方都没有存储秘密（如流程＃1）。（这里是总结）

您的示例使用#2，如response_type=token

access_token通常以以下形式的 URL 返回：

http://{callback}/#access_token={the access token}

当浏览器尝试导航到该地址时，WebAuthenticationBroker将中断导航并调用您的代码。然后，您将提取access_token并执行您的应用程序对 AS（或您的 API）所做的任何事情。

此示例展示了如何使用它（使用我们自己的 AS，但您可以轻松地将其推广到任何 AS）。

注意：access_tokens通常是不透明的实体。没有加密或签名或任何东西。更现代的系统将返回一个Json Web Token，它确实具有意义和内容并且是数字签名的。在上面的示例中，您将看到id_token除了access_token. 那是一个智威汤逊。

于 2013-10-13T18:56:59.467 回答