我目前正在实施Oauth消费者服务，该服务也将使用Soundcloud作为Oauth服务提供商。但是我遇到了以下问题：以Facebook或Twitter为例，你去那里，你登录，填写许可表格，然后你被重定向回你的应用程序。如果你第二次去那里，并且鉴于你已经登录，你基本上会跳过所有步骤并立即重定向。这意味着，Facebook认识到您已经允许该第三方服务，因此它不会经常征得您的许可。
这就是我使用Soundcloud时发生的事情。基本上每当我将用户重定向到Soundcloud Oauth连接端点时，即使我之前已经允许该第三方服务，也会显示权限表单。我不得不每次都按“连接”，这是从用户角度来看的拖累（你可以多少次授予同一个实体）。我的问题是：是否有一个参数可用于使soundcloud识别/验证用户帐户之前对该特定第三方服务的许可？或者这是Soundcloud Oauth的设计实现，我们必须忍受它吗？
编辑：
也许这还不清楚，但每次我在soundcloud中按“connect”时，都会生成并传递一个新的访问令牌。由于我的应用程序使用此访问令牌来识别其用户，因此每次我想要登录时访问令牌都会更新，这对我来说效果不佳，这使我每次都能有效地“注册”。总结一下，我希望将以前归因的令牌添加到我的帐户中，这样我就可以在我的数据库中查找，识别并登录。
我也在寻找一种解决方案，它不涉及在客户端中存储可能被清理的状态。
答案 0 :(得分：2)
您可以做的是将用户的oauth令牌存储在本地存储中，并在将来的会话中重复使用它。这就是soundcloud.com上发生的事情。
更长的解释：
当您使用Connect流程时，用户将通过SoundCloud进行身份验证（使用用户名/密码，Facebook Connect或soundcloud.com上已有的会话），然后在成功时，您的应用程序将被授予该用户的oauth令牌。这将传递到为您的应用注册的回调页面。
该令牌是让用户登录＆＃34;所需的唯一信息。除非令牌过期（按时间或由用户手动撤销），否则您可以在将来的会话中重复使用该令牌。
我认为我对您的应用程序的设计感到有点困惑：oauth令牌在哪里以及如何使用？我认为不是使用令牌作为标识符，也许用户的永久链接可能更好？如果您有oauth令牌，则可以通过查询api.soundcloud.com/me找到永久链接。