标签: oauth

我真的想了解OpenID和OAuth之间的区别吗？也许他们是两个完全不同的东西？

OAuth 2.0协议草案的4.2节指出授权服务器可以返回a access_token(用于向资源验证自己)以及a refresh_token,它纯粹用于创建新的access_token:

https://tools.ietf.org/html/rfc6749#section-4.2

为什么两者都有？为什么不只是做到access_token最后只要refresh_token没有refresh_token？

用非常简单的术语来说,有人可以解释OAuth 2和OAuth 1之间的区别吗？

OAuth 1现在已经过时了吗？应该实施OAuth 2吗？我没有看到很多OAuth 2的实现; 大多数人仍在使用OAuth 1,这让我怀疑OAuth 2已经可以使用了.是吗？

我有一个HttpClient,我用它来使用REST API.但是,我在设置Authorization标头时遇到问题.我需要将标头设置为我从执行OAuth请求时收到的令牌.我看到.NET的一些代码表明以下内容,

httpClient.DefaultRequestHeaders.Authorization = new Credential(OAuth.token);

但是,Credential类在WinRT中不存在.任何人有任何想法如何设置授权标头？

我想使用ASP.NET Web API 构建RESTful Web服务,第三方开发人员将使用它来访问我的应用程序的数据.

我已经阅读了很多关于OAuth的内容,它似乎是标准的,但找到一个很好的样本,文档解释它是如何工作的(实际上确实有效!)似乎非常困难(特别是对于OAuth的新手).

是否有实际构建和工作的示例,并说明如何实现它？

我已经下载了很多样本​​:

• DotNetOAuth - 从新手的角度来看,文档是没有希望的
• Thinktecture - 无法构建它

我还看过一些博客,建议一个简单的基于令牌的方案(像这样) - 这似乎重新发明了轮子,但它确实具有概念上相当简单的优势.

似乎在SO上有很多这样的问题,但没有好的答案.

每个人在这个领域做什么？

我有一个使用JWT的无状态身份验证模型的新SPA.我经常被要求引用OAuth进行身份验证流程,例如要求我为每个请求发送"Bearer tokens"而不是简单的令牌标头,但我认为OAuth比简单的基于JWT的身份验证要复杂得多.如果JWT身份验证的行为与OAuth相似,主要区别是什么？

我也使用JWT作为我的XSRF-TOKEN以防止XSRF,但我被要求将它们分开？我应该将它们分开吗？这里的任何帮助将不胜感激,并可能为社区带来一套指导方针.

任何人都可以解释OAuth2有什么好处以及为什么要实现它？我问,因为我对它有点困惑 - 这是我目前的想法:

OAuth1(更准确地说是HMAC)请求看起来合乎逻辑,易于理解,易于开发,而且非常安全.

相反,OAuth2会带来授权请求​​,访问令牌和刷新令牌,您必须在会话开始时发出3个请求才能获取您所追踪的数据.即便如此,当令牌过期时,您的一个请求最终会失败.

要获取另一个访问令牌,您可以使用与访问令牌同时传递的刷新令牌.从安全角度来看,这是否会使访问令牌徒劳无功？

另外,正如/ r/netsec最近所展示的那样,SSL并非完全安全,因此将所有内容都放到TLS/SSL而非安全HMAC上的努力让我感到困惑.

OAuth认为它不是100%的安全性,而是将其发布和完成.从提供商的角度来看,这听起来并不乐观.我可以看到草案在提到6种不同的流量时试图实现的目标,但它并没有在我脑海中融合在一起.

我认为可能更难以理解它的好处和推理而不是实际上不喜欢它,所以这可能是一种无根据的攻击,如果这看起来像是一种咆哮,那就很抱歉.

我不知道我是否只是有某种盲点或什么,但我已多次阅读OAuth 2规范并仔细阅读邮件列表档案,我还没有找到一个很好的解释为什么隐含格兰特已经开发出用于获得访问令牌的流程.与授权代码授予相比,似乎只是放弃了客户端身份验证,没有非常令人信服的理由.这是如何"针对使用脚本语言在浏览器中实现的客户端进行优化"(引用规范)？

两个流程都是相同的(来源:http://tools.ietf.org/html/draft-ietf-oauth-v2-22):

1. 客户端通过将资源所有者的用户代理指向授权端点来启动流.
2. 授权服务器对资源所有者进行身份验证(通过用户代理),并确定资源所有者是否授予或拒绝客户端的访问请求.
3. 假设资源所有者授予访问权限,授权服务器使用先前提供的重定向URI(在请求中或在客户端注册期间)将用户代理重定向回客户端.
   • 重定向URI包括授权代码(授权代码流)
   • 重定向URI包括URI片段中的访问令牌(隐式流)

这是流量分裂的地方.在这两种情况下,此时重定向URI都是由客户端托管的某个端点:

• 在授权代码流中,当用户代理使用URI中的授权代码命中该端点时,该端点上的代码会将授权代码及其客户端凭据交换为访问令牌,然后可以根据需要使用该令牌.例如,它可以将其写入页面上的脚本可以访问的网页中.
• Implicit流完全跳过此客户端身份验证步骤,只是加载带有客户端脚本的网页.这里有一个可爱的技巧,URL片段可以防止访问令牌过多传递,但最终结果基本相同:客户端托管的站点提供一个页面,其中包含一些可以获取访问令牌的脚本.
  

因此我的问题是:通过跳过客户端身份验证步骤获得了什么？

使用"隐式"流程,客户端(可能是浏览器)将在资源所有者(即用户)提供访问权限后获得访问令牌.

但是,通过"授权代码"流程,客户端(通常是Web服务器)仅在资源所有者(即用户)授予访问权限后才获取授权代码.使用该授权代码,客户端再次调用API,将client_id和client_secret与授权代码一起传递,以获取访问令牌.这里描述的都很好.

两个流都具有完全相同的结果:访问令牌.但是,"隐式"流程要简单得多.

问题:当"隐式"流程接缝没问题时,为什么要打扰"授权代码"流程呢？为什么不对webserver使用"Implicit"？

这对提供商和客户来说都是更多的工作.

首先让我说我已经搜索了这个问题的答案已经有一段时间了......

我正在尝试设置Facebook OAuth以使用我的机器上本地开发的应用程序.一切都与Facebook授权完美配合UNTIL我从使用localhost转移到另一个域名(仍然是我的机器本地.)现在我收到以下错误.

无法加载网址:此网址的域名未包含在应用的域中.要加载此网址,请将应用的所有域和子域添加到应用设置中的应用域名字段中.

我的主机文件包含127.0.0.1 photovote.dev (完美的工作)

我的应用程序中的重定向(使用Socialite)是 http://photovote.dev/auth/facebook/callback

在我的Facebook应用程序设置中...

• 我的App域名是 photovote.dev
• 我的网站网址是 http://photovote.dev/
• 我的有效OAuth重定向URI是 http://photovote.dev/auth/facebook/callback

错误消息时的URL是..

https://www.facebook.com/v2.5/dialog/oauth?client_id=XXXXXXXXXXXXXXX&redirect_uri=http%3A%2F%2Fphotovote.dev%2Fauth%2Ffacebook%2Fcallback&scope=email&response_type=code&state=0ztcKhmWwFLtj72TWE8uOKTcf65JmePtG95MZLDD

我不知道问题是什么......

屏幕截图1

屏幕截图2