即使提出这个问题，我也感到愚蠢，但我的理解极限，希望有人可以提供一些背景。
我正在查看以下内容（https://stormpath.com/blog/token-auth-for-java/），其中指出：
access_token 是浏览器在后续请求中使用的内容... 授权标头是标准标头。使用OAuth2不需要自定义标头。而不是类型是Basic，在这种情况下，类型是承载。访问令牌直接包含在Bearer关键字之后的。
我正在建立一个网站，我将为后端REST服务以及前端浏览器客户端编写代码。鉴于此背景，为什么我需要遵循上面给出的任何指导原则？什么阻止我使用我喜欢的任何关键字，或者在标题中完全跳过 Bearer 关键字，而不是使用 access_token，Authorization和Bearer 关键字？毕竟，只要前端和后端服务都以一致的方式读/写数据，不应该一切正常吗？
上面给出的关键字和指南是否只是最佳实践建议，以帮助其他人更好地理解您的代码/服务？它们类似于编码风格吗？或者不遵守上述指导方针是否有任何功能影响？
答案 0 :(得分：1)
鉴于此背景，为什么我需要遵循上面给出的任何指导原则？
因为它们是标准化的规范，如果每个人都希望彼此互动，那么每个人都应该遵守这些规范。
不是使用 access_token，授权和承载关键字，而是阻止我使用我喜欢的任何关键字，或完全跳过 Bearer 关键字头？
没什么，除了它不再是OAuth。除非您为自己发布自己的规范，否则这将是您为自己创建的自定义内容，除非您发布自己的规范，否则将无法理解如何使用。
毕竟，只要前端和后端服务以一致的方式读/写数据，一切都不能正常工作吗？
谁能说你一个人只会写出唯一的前端？或者说后端永远不会移动到另一个平台？当有这种东西的开放标准时，不要限制自己制作一些自定义的东西。
上面给出的关键字和指南是否只是最佳做法建议，以帮助其他人更好地理解您的代码/服务？
没有。它们是必需的协议元素，可帮助客户端和服务器以标准化方式相互通信。
Authorization是用于身份验证的标准HTTP标头。它有一个类型，因此客户端可以指定它使用的是哪种认证方案（Basic vs NTLM vs Bearer等）。客户端必须指定正在使用的正确方案，并且服务器只能处理它识别的方案。
承载是OAuth在Authorization标头中使用的身份验证的类型。 access_token 是OAuth的承载身份验证的参数。
如果您使用Authorization标题（您应该使用），必须指定类型，这是RFC 2616和{{ {3}}：
Authorization = "Authorization" ":" credentials credentials = auth-scheme #auth-param auth-scheme = token auth-param = token "=" ( token | quoted-string )
因此，在这种情况下，承载是auth-scheme， access_token 是auth-param。
它们是否类似于编码风格？
没有
或者不遵守上述指导方针是否有任何功能影响？
是。使用自定义身份验证系统的客户端将无法在遵循既定规范的任何服务器上进行身份验证。您的服务器将无法对不使用自定义身份验证系统的任何客户端进行身份验证。