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