移动应用程序中的OAuth秘密

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (12)

当使用OAuth协议时,需要从要委托给的服务中获得一个秘密字符串。如果你是在网络应用程序中这样做,你可以简单地将秘密存储在数据库或文件系统中,但是在移动应用程序(或桌面应用程序)中处理秘密的最佳方法是什么?

我能想到的唯一可行的解决方案是,首先获得正常的访问令牌(最好在应用程序中使用Web视图),然后通过我们的服务器路由所有进一步的通信,这将把秘密附加到请求数据并与提供者通信。

提问于
用户回答回答于

是的,这是我们自己面对的OAuth设计的一个问题。我们选择通过自己的服务器代理所有调用。在桌面应用方面,OAuth并没有被完全淘汰。没有完美的解决方案,我已经找到了不改变OAuth。

有秘密,主要是为了提供和禁用应用程序。如果我们的秘密被泄露,那么提供者只能真正地撤销整个应用程序。

解决方案是对每个桌面应用程序都有不同的秘密。OAuth并没有让这个概念变得简单。一种方法是让用户自己去创建一个秘密,然后在你的桌面应用程序中输入自己的密钥(一些Facebook应用程序很长时间都做了类似的事情,让用户去创建Facebook来建立他们的定制查询和垃圾)。对于用户来说,这不是一个很好的体验。

我正在为OAuth制定一个授权制度的提案。我们的概念是,使用我们自己从我们的提供商那里获得的密钥,我们可以向我们自己的桌面客户端发布我们自己的委托秘密(基本上每个桌面应用程序都有一个),然后在第一个过程中,我们将该密钥发送给顶级的提供者,该提供者会给我们回电话,并与我们一起重新验证。这样,我们就可以撤销对每个桌面客户端发布的机密信息。(借用了许多SSL的工作原理)。这整个系统将是完美的增值网络服务,以及传递给第三方网络服务调用。

如果顶级提供程序提供了一个API来生成和撤销新的委托机密,则无需委托验证回调就可以完成此过程。facebook也在做类似的事情,允许facebook应用程序允许用户创建子应用程序。

用户回答回答于

使用OAuth2.0,可以将秘密存储在服务器上。使用服务器获取访问令牌,然后移动到应用程序,然后可以从应用程序直接调用资源。

使用OAuth1.0(Twitter),进行API调用需要保密。通过服务器代理调用是确保秘密不被泄露的唯一方法。

两者都需要某种机制,使服务器组件知道是客户机调用它。这往往是在安装和使用特定于平台的机制来获取对服务器的调用中某种类型的应用程序ID时完成的。

扫码关注云+社区