当您在iOS应用和服务器中使用令牌时，如何处理Facebook对offline_access的弃用 [英] How to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server

问题描述

Facebook的弃用的 offline_access 权限即将到来2012年5月，文档没有给我们足够的信息，如何处理它。

我们有一个iOS应用程序和相应的服务为Facebook提供强大的功能，并与Facebook进行深入整合，以利用用户的朋友列表（如果您的FB朋友也使用该应用，您可以更轻松地连接）。这就像所有的社交应用程序似乎都有效，所以没有什么特别的。

客户端

我们的应用使用 Facebook iOS SDK 允许用户登录，我们目前请求 offline_access 。令牌持久存在于我们的iOS应用程序中，同时也被发送到我们的服务器。客户端代表用户对用户的新闻源进行更新（我们也要求 publish_stream 权限）。

服务器

我们的服务器定期检查用户的FB朋友是否现在用我们的应用程序下次用户登录时，我们以某种方式公开内容和关系，以促进该用户的朋友。服务器还代表用户行事，定期连接到图形API，并获得用户当前的朋友列表。这是我们可以解释用户关系的变化，并将其反映在我们的应用程序中。当用户当前没有使用该应用程序，以便下次使用该应用程序时，他们有最好的体验，我们这样做。为了实现这一点，我们的iOS应用将访问令牌发送到我们使用的服务器，为什么我们要求 offline_access 。

注意：如果用户明确地退出我们的应用程序，我们将从客户端和服务器上删除访问令牌。

问题

现在我们可以使用永久访问令牌，找出在实现我们的场景的最佳实践，同时利用Facebook的新的预期方式来处理和扩展访问令牌。文件不幸不是完全有用的。

问题

A 。当您通过最新的Facebook iOS SDK进行身份验证时，您获得的访问令牌的默认生命周期是多少？ 本文档表示扩展令牌请求将给您一个持续60天的请求。此其他文档介绍了第一个访问令牌请求，并提到不同的有效性，但它是不清楚，它是否谈到具体的有效期：

（重点是我的）

当您从Facebook获取访问令牌时，将立即生效
可用于API定义的某些时间段
的请求。在这段时间过后，访问令牌
被认为已经过期，用户将需要再次
进行身份验证，以便您的应用程序获取新的访问
令牌。 给定访问令牌的有效期限取决于
如何生成。

还有可能导致的事件在其预期到期时间之前成为
的访问令牌无效。这样的事件包括用户
更改其密码，应用程序刷新它的App Secret。
处理不同的访问令牌到期时间，并且在访问令牌在其预期到期时间之前变得无效时处理案例

对于构建强大的社交体验至关重要。

B。对于客户端，现在访问令牌不一定很长寿命，对我们来说是正确的方法： / p>

允许通过FB登录，然后在访问令牌过期时进行检测。如果是，请拨打FB iOS SDK重新认证/重新授权？ （这应该只是触发用户弹跳到FB iOS应用程序，在大多数情况下，立即返回到我们的应用程序，使用新的访问令牌）。

C 。根据此博客文章我发现，你只能扩展访问令牌一次：

我可以交换我的60天访问令牌为新的60日访问令牌？

不，对不起，你不能。您只能为扩展的一个交换一个有效的（意思是当前）
用户访问令牌。您不能扩展已经
的扩展访问令牌。

在客户端上，我可以通过提示重新启动认证/重新授权，如我在问题B中提到的。但是，这在我们的服务器上不起作用。我们当然可以让服务器更新一次至60天，但是在第61天会怎么样？服务器只是停止能够同步朋友的列表？

D。似乎有意义的是检查FB访问令牌的有效性每次应用程序启动或从睡眠中恢复水合。什么是我们的iOS应用程序检查这个最好的方法？是否有推荐的端点来调用验证令牌？我们应该调用 https://graph.facebook.com/me 传递访问令牌并检查响应？

注意：当我们获得最初的扩展令牌时，我们可以记录 expires 的时间，但这并不可靠，因为用户可以随时撤销我们的应用的权限到期时间

解决方案

概述

我相信Facebook正在努力实现的根本在于防止应用永久访问用户的帐户。因此，通过新的迁移，只有用户再次登录，应用才能访问帐户60天。

我不适用于Facebook，但这是我通过facebook图表API进行的调查结果。

一般解决方案

1. 每当用户登录时，都可以使用他们的访问令牌并立即扩展/刷新它，并保存


2. 记录访问令牌的到期日期


3. 当访问令牌过期时（从记录的日期或图形API异常告诉你），然后通知用户你没有访问权限，并要求他们再次登录。

答案

A。当您通过最新的Facebook iOS SDK进行身份验证时，您获得的访问令牌的默认生命周期是多少？这个文件说一个扩展的令牌请求会给你一个持续60天。这个其他文件谈到了第一个访问令牌请求，并提到不同的有效性，但不清楚，并且具体说明具体的有效期：

如何工作：

1. 第一次登录会给您大约两个小时


2. 通过刷新访问令牌，您最多可以获得60天


3. 如果用户未登录这60天，则无法访问更长时间，无需登录。 / li>
   
4. 如果用户取消授权您的应用，那么60天的窗口会立即结束，您将无法再访问。

B。对于客户端来说，现在访问令牌不一定很长寿命，对我们来说是正确的方法：让我们通过FB登录，然后在访问令牌过期时检测。如果是，请拨打FB iOS SDK重新认证/重新授权？ （这应该只是触发用户弹跳到FB iOS应用程序，在大多数情况下，立即返回到我们的应用程序一个新的访问令牌）。

如果用户访问令牌已过期，您唯一的选择是让他们通过登录循环，如您所说的。

℃。根据这篇博文发现，你只能扩展访问令一次。在客户端，我可以通过提示重新验证/重新授权来处理这个问题，如我在问题B中提到的。但是，这在我们的服务器上不起作用。我们当然可以让服务器更新一次至60天，但是在第61天会怎么样？服务器只能停止同步朋友的列表？

您只能扩展访问令牌一次。在第61天，你没有运气。最好通知用户，让他们知道，除非他们登录，否则您将无法做任何事情。

D。每次应用程序启动或从睡眠恢复水合物时，检查FB访问令牌的有效性似乎是有意义的。什么是我们的iOS应用程序检查这个最好的方法？是否有推荐的端点来调用验证令牌？我们应该打电话给 https://graph.facebook.com/me 传递访问令牌并检查回复？

我无法找到相当于调试控制台。 此FB博客文章谈论无效的访问令牌，但没有提到任何API方法，特别是测试API。

我建议您点击 https://graph.facebook.com/me 将正常工作正是他们在他们的例子。事实上，我可以在我的应用程序中使用这种方法作为检查访问令牌的主动方式。

Tid Bits

• 当您刷新访问令牌时，将返回新的访问令牌。响应如下： access_token = TOKEN& expires = 5183912


• 您只能刷新一次访问令牌。如果您尝试刷新从前一次调用返回的长命令，则它将返回相同的令牌，但不会抛出异常，除非令牌已过期。 （换句话说，您可以安全地尝试刷新您的令牌）


• 默认访问令牌长度似乎约为2小时


• 如果您刷新一个访问令牌，新的访问令牌似乎是您之后从Facebook API获得的令牌（而不是返回原始的短命令访问令牌）

另外，如果你想玩，这些工具可以很容易地在浏览器中测试您的用例，然后将其掩盖在代码中：

• Graph API Explorer - 用于创建和获取访问令牌


• 调试控制台 - 用于检查到期日期刷新之前/之后的令牌


• 刷新端点 - 手动测试扩展你的标记

Facebook's deprecation of the offline_access permission is coming May 2012 and the documentation isn't giving us enough information on how to handle it.

We have an iOS app and corresponding service that powers it and integrates with Facebook in a deep way to leverage a user's friend list within out app (so if your FB friends are also using the app you can more easily connect). This is like how all social apps seem to work, so nothing special here.

Client

Our app uses Facebook iOS SDK to allow user to login, which we currently ask for offline_access. The token is persisted in our iOS app, but also sent to our server where it is saved. The client acts on behalf of user to post updates to a user's newsfeed (we also ask for publish_stream permission).

Server

Our server periodically checks to see if user's FB friends are now using our app. Next time user signs in, we expose content and relationships in a certain way to promote that user's friends. The server also acts on behalf of the user to periodically connect to the graph API and get the user's current friends list. This is so we can account for changes in a user's relationships and have them reflected in our app. We do this when the user isn't currently using the app so they have the best experience the next time they do use it. To enable this, our iOS app sends the access token to our server which it uses and why we ask for offline_access.

Note: If user signs out of our app explicitly, we delete the access tokens from both client and server.

Problems

Now that there is no longer a perpetual access token we can use, I'm trying to figure out the best practice for still enabling our scenarios while leveraging facebook's new intended way of handling and extending access tokens. The documentation is unfortunately not totally helpful.

Questions

A. When you authenticate through the newest Facebook iOS SDK, what is the default lifetime of the access token you get? This document says an extended token request will give you one that lasts 60 days. This other document talks about the first access token request and mentions varying validities but it's unclear and does it talk about specific validity times:

(emphasis is mine)

When you obtain an access token from Facebook, it will be valid immediately and usable in requests to the API for some time period defined by Facebook. After that period has elapsed, the access token is considered to have expired and the user will need to be authenticated again in order for your app to obtain a fresh access token. The duration for which a given access token is valid depends on how it was generated.

There are also events which may cause an access token to become invalid before its expected expiry time. Such events include the user changing their password, an application refreshing it's App Secret. Dealing with varying access token expiry times, and handling the case when an access token becomes invalid before its expected expiry time is essential for building robust social experiences.

B. For the client, now that the access token isn't necessarily long lived, is the right approach for us to:

Let use login through FB, then detect whenever the access token is expired. If it is, then call into FB iOS SDK to re-authentication/re-authorize? (this should just trigger user to bounce out to FB iOS app, and in most cases come immediately back to our app with a new access token).

C. According to this blog post I found, you can only extend an access token once:

Can I exchange my 60 day access token for a new 60 day access token?

No, sorry you cannot. You can only exchange a valid (meaning current) user access token for an extended one. You cannot extend an already extended access token.

On the client, I can just handle this by prompting a re-authentication/re-authorization as I mentioned in Question B. However, this doesn't work on our server. We could certainly have the server renew it once to 60 days, but what happens on the 61st day? The server just stops being able to sync the friend's list?

D. It seems to make sense to check the validity of the FB access token every time the app starts or re-hydrates from sleep. What is the best way for our iOS app to check this? Is there a recommended endpoint to call to validate a token? Should we just call into https://graph.facebook.com/me passing the access token and checking the response?

Note: we can certainly record the expires time when we get the initially extended token, but this isn't reliable since the user could revoke our app's permission anytime which makes the expires time an unreliable data point on validity

解决方案

Overview

I believe that the root of what facebook is trying to achieve is to prevent an app from having perpetual ever-lasting access to a user's account. So, with the new migration an app can only access an account for 60 days unless the user signs in again.

I don't work for facebook, but here are my findings from playing around with the facebook graph api.

General Solution

1. Whenever a user signs in, take their access token and immediately extend/refresh it, and save it
2. Record the expiration date of the access token
3. When an access token expires (either from the recorded date, or a graph API exception telling you so), then notify the user that you don't have access, and ask them to sign in again.

Answers

A. When you authenticate through the newest Facebook iOS SDK, what is the default lifetime of the access token you get? This document says an extended token request will give you one that lasts 60 days. This other document talks about the first access token request and mentions varying validities but it's unclear and does it talk about specific validity times:

Here's how it works:

1. The first sign-in grants you approximately two hours
2. By refreshing the access token, you can get up to 60 days
3. If the user doesn't sign in to those 60 days, there is no way to get access for longer without having them sign in.
4. If the user de-authorizes your app, that 60 day windows ends immediately, and you will no longer have access.

B. For the client, now that the access token isn't necessarily long lived, is the right approach for us to: Let use login through FB, then detect whenever the access token is expired. If it is, then call into FB iOS SDK to re-authentication/re-authorize? (this should just trigger user to bounce out to FB iOS app, and in most cases come immediately back to our app with a new access token).

If the users access token is expired, your only option is to have them go through a login loop like you are talking about.

C. According to this blog post I found, you can only extend an access token once. On the client, I can just handle this by prompting a re-authentication/re-authorization as I mentioned in Question B. However, this doesn't work on our server. We could certainly have the server renew it once to 60 days, but what happens on the 61st day? The server just stops being able to sync the friend's list?

You can only extend an access token once. On the 61st day, you are out of luck. Best notify the user and let them know that unless they sign in, you won't be able to do anything.

D. It seems to make sense to check the validity of the FB access token every time the app starts or re-hydrates from sleep. What is the best way for our iOS app to check this? Is there a recommended endpoint to call to validate a token? Should we just call into https://graph.facebook.com/me passing the access token and checking the response?

I haven't be able to find an API equivalent of the Debug Console. This FB blog article talks about invalidated access tokens, but doesn't mention any API methods in particular meant to test the API.

I your suggestion of hitting https://graph.facebook.com/me would work just fine is exactly what they recommend in their example. In fact, I might use this approach in my app as a pro-active way of checking an access token.

Tid Bits

• When you "refresh" an access token, a new access token will be returned. The response looks like: access_token=TOKEN&expires=5183912
• You can only "refresh" an access token once. If you try to "refresh" the long-lived token returned from a previous call, it will return the same token, but doesn't throw an exception unless the token has expired. (in other words, you can safely try to refresh your token)
• The default access token length seems to be around 2 hours
• If you "refresh" an access token, that new access tokens seems to be the one that you'll get from the facebook API afterwards (instead of returning the original, short-lived access token)

Also, if you want to play around, these tools make it easy to test out your use case in a browser before burying it in your code:

• Graph API Explorer - For creating and getting access tokens
• Debug Console - For checking the expiry date of tokens before/after refresh
• Refresh Endpoint - For manually testing extending your tokens

这篇关于当您在iOS应用和服务器中使用令牌时，如何处理Facebook对offline_access的弃用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！