我在 Facebook 工作，对此我可以给出明确的答案。
请不要为访问令牌的存储设置最大大小。我们预计，随着我们添加和删除数据并更改它们的编码方式，它们会随着时间的推移而增长和缩小。
我们确实在一个地方给出了关于它是 255 个字符的指导。我更新了包含该信息的博客文章并更新了我们的新访问令牌文档以包含有关大小的注释：
https://developers.facebook.com/docs/facebook-login/access-tokens/
对困惑感到抱歉。
随着 Facebook 最近转向加密访问令牌，访问令牌的长度可以达到 255 个字符。如果您将访问令牌存储在数据库中，则该列应该至少能够容纳 varchar(255)。以下是 2011 年 10 月 4 日 Facebook 开发者博客的摘录：
“启用加密访问令牌迁移后，访问令牌的格式已更改。新的访问令牌格式完全不透明，您不应依赖代码中的格式。varchar(255) 字段足以存储新令牌。”
完整的博文在这里：https://developers.facebook.com/blog/post/572
这个答案不再正确，我在 FB 的文档中找不到更正的值。我们收到了超过 255 个字符的访问令牌。我们正在从 VARCHAR 转移到 SMALLTEXT，而不是尝试面向未来的事情。
SMALLTEXT 还是 MEDIUMTEXT？我以前也将我的 access_token 限制为 VARCHAR(255)，我今天正在处理它的后果。
来自 The OAuth 2.0 Authorization Protocol (draft-ietf-oauth-v2-22) 的第 1.4 节
根据资源服务器的安全要求，访问令牌可以具有不同的格式、结构和使用方法（例如加密属性）。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，由配套规范定义。
我查找了“配套规范”，但没有找到任何相关内容，并且在第 11.2.2 节中指出
参数名称：access_token o 参数使用位置：授权响应、令牌响应 o 变更控制器：IETF o 规范文档：[[ 本文档]]
这似乎表明 access_token 参数是在本规范中定义的。我猜这个参数是，但实际的访问令牌并没有完全充实。
更新：此规范编写的最新版本 (draft-ietf-oauth-v2-31) 包括一个附录，该附录更好地定义了 access_token 参数的期望
A.12。 "access_token" 语法 "access_token" 元素在第 4.2.2 节和第 5.1 节中定义： access-token = 1*VSCHAR
所以本质上这意味着 access_token 应该至少有 1 个字符长，但本规范中定义的长度没有限制。
请注意，他们定义 VSCHAR = %x20-7E
Facebook 访问令牌可以超过 255 个字符。我有很多错误，例如 ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255)，其中的值是 facebook 访问令牌。不要使用 string 类型的列，因为它的长度是有限的。您可以使用 text 类型列来存储令牌。
最近，我们的应用程序看到它们超过 100 个字符。我仍在寻找文档，以便为他们找出“安全”的字段大小。
我会根据花费的时间更新答案。
从 OAuth2 文档中，
本规范未定义访问令牌字符串大小。客户应避免对价值大小做出假设。授权服务器应该记录它发出的任何值的大小。
（this document 的第 4.2.2 节）
注意：Facebook 正在使用 OAuth2，如 this page 中所述。
所以现在，Facebook 的开发者门户上似乎没有关于 OAuth 令牌长度的信息。 Yahoo 似乎使用 400 位长的标记，因此最好假设 MySQL 中的 TEXT 列比 varchar 更安全。
