标签: oauth-2.0

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

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

据我了解,OAuth 2中发生以下事件链,以便Site-A从中访问用户的信息Site-B.

1. Site-A注册Site-B,并获得一个秘密和一个ID.
2. 当用户告诉Site-A访问时Site-B,用户被发送到Site-B他告诉Site-B他确实想要授予Site-A特定信息权限的位置.
3. Site-B重定向用户回Site-A,用授权码来一起.
4. Site-A然后将该授权码连同其秘密一起传递回Site-B安全令牌.
5. Site-A然后通过捆绑安全令牌和请求来Site-B代表用户发出请求.

所有这些在高级别上如何在安全性和加密方面起作用？OAuth 2如何使用安全令牌防止重放攻击等事情？

在网站https://code.google.com/apis/console上我已经注册了我的应用程序,为我的应用设置了生成的客户端ID:和客户端密钥,并尝试使用Google登录.不幸的是,我收到了错误消息:

Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI

scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id

这条消息是什么意思,我该如何解决？我使用gem omn​​iauth-google-oauth2.

任何人都可以解释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"？

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

我刚刚开始使用Google API和OAuth2.当客户端授权我的应用程序时,我会获得一个"刷新令牌"和一个短暂的"访问令牌".现在每次访问令牌到期时,我都可以将刷新令牌发送给Google,他们会给我一个新的访问令牌.

我的问题是访问令牌到期的目的是什么？为什么不能只使用持久访问令牌而不是刷新令牌？

此外,刷新令牌是否到期？

有关Google OAuth2工作流程的详细信息,请参阅使用OAuth 2.0访问Google API.

初学者程序员在这里,请原谅无知和解释会非常好:)

我曾尝试阅读某个OAuth 2.0服务的教程,但我不理解这个重定向URI ...在我的特定上下文中,假设我正在尝试构建一个使用OAuth 2.0进行某些服务的iPhone应用程序.我有一个生成的应用程序ID,但我需要提供某种重定向URI来生成API密钥.

这是一个我应该在某处自己托管的网址吗？顾名思义,我认为重定向URL应该在某个地方"重定向"某人.我唯一的猜测是,这是用户登录服务后重定向到的URL.

但是,即使这个假设是正确的,我也不明白另一件事 - 在我将应用程序发送到浏览器进行用户登录后,我的应用程序如何再次打开？

OAuth 2.0具有多个工作流程.关于这两个,我有几个问题.

1. 授权代码流 - 用户从客户端应用程序登录,授权服务器向应用程序返回授权代码.然后,应用程序交换访问令牌的授权码.
2. 隐式授权流程 - 用户从客户端应用程序登录,授权服务器直接向客户端应用程序发出访问令牌.

这两种方法在安全性方面有什么区别？哪一个更安全,为什么？

当服务器可以直接发出Access令牌时,我没有看到为什么在一个工作流中添加额外步骤(令牌的交换授权代码)的原因.

不同的网站说,当客户端应用程序可以保证凭据安全时,使用授权代码流.为什么？

我正在尝试按照https://developers.google.com/console/help/#installed_applications中的步骤注册我的Android应用, 这导致我关注 http://developer.android.com/tools/publishing/app-签名.

但是,我不知道如何获得签名证书指纹(SHA1).

我首先使用Eclipse ADT插件导出并创建密钥库/密钥.然后,我尝试了keytool -list keystore mykeystore.keystore,它给了我一个MD5证书指纹.我是否需要重做签名(意味着我无法使用eclipse导出向导)？

我可以先使用调试证书吗？