为什么我需要遵循 OAuth spec/guidelines？
Why do I need to follow the OAuth spec/guidelines?
我什至觉得问这个问题很傻，但在我的理解范围内，希望有人能提供一些背景信息。
我正在查看以下内容 (https://stormpath.com/blog/token-auth-for-java/)，其中指出：
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
我正在构建一个网站，我将为此编写 back-end REST 服务以及 front-end 浏览器客户端。鉴于这种情况，为什么我需要遵循上面给出的任何指导方针？不是使用 access_token、Authorization 和 Bearer 关键字，是什么阻止我使用我喜欢的任何关键字，或跳过 Bearer 关键字完全在 header?毕竟，只要 front-end 和 back-end 以一致的方式为这两个 read/write 数据提供服务，难道不是一切正常吗？
上面给出的关键字和指南是否只是 best-practice 建议，以帮助其他人更好地理解您的 code/service？它们类似于 coding-styles 吗？或者不遵守上述准则是否会影响功能？
Given this context, why do I need to follow any of the guidelines given above?
因为它们是标准化规范，如果每个人想要相互交流，都必须遵守这些规范。
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
没什么，只是它不再是 OAuth。这将是您为自己创建的自定义内容，除非您发布自己的规范，否则没有人会理解如何使用它。
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
谁说只有你一个人才能写出唯一的front-end？或者 back-end 永远不会移动到另一个平台？当这类东西有开放标准时，不要局限于定制某些东西。
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
没有。它们是帮助客户端和服务器以标准化方式相互通信的必需协议元素。
Authorization 是用于身份验证的标准 HTTP header。它有一个 type，因此客户端可以指定它使用的是哪种身份验证方案（Basic vs NTLM vs Bearer，等等）。重要的是客户端指定正在使用的正确方案，并且服务器只处理它识别的方案。
Bearer 是 OAuth 在 Authorization header 中使用的 type 身份验证。 access_token是OAuth的Bearer认证的参数。
如果您使用 Authorization header（您应该使用），您 必须 指定 类型 ，根据 RFC 2616 and 2617:
的要求
Authorization = "Authorization" ":" credentials
credentials = auth-scheme #auth-param
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
所以，在这种情况下，Bearer 是 auth-scheme 而 access_token 是 auth-param.
Are they analogous to coding-styles?
没有
Or is there any functional impact in not following the above guidelines?
是的。使用您的自定义身份验证系统的客户端将无法在任何遵循既定规范的服务器上进行身份验证。您的服务器将无法验证任何不使用您的自定义身份验证系统的客户端。
我什至觉得问这个问题很傻，但在我的理解范围内，希望有人能提供一些背景信息。
我正在查看以下内容 (https://stormpath.com/blog/token-auth-for-java/)，其中指出：
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
我正在构建一个网站，我将为此编写 back-end REST 服务以及 front-end 浏览器客户端。鉴于这种情况，为什么我需要遵循上面给出的任何指导方针？不是使用 access_token、Authorization 和 Bearer 关键字，是什么阻止我使用我喜欢的任何关键字，或跳过 Bearer 关键字完全在 header?毕竟，只要 front-end 和 back-end 以一致的方式为这两个 read/write 数据提供服务，难道不是一切正常吗？
上面给出的关键字和指南是否只是 best-practice 建议，以帮助其他人更好地理解您的 code/service？它们类似于 coding-styles 吗？或者不遵守上述准则是否会影响功能？
Given this context, why do I need to follow any of the guidelines given above?
因为它们是标准化规范，如果每个人想要相互交流，都必须遵守这些规范。
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
没什么，只是它不再是 OAuth。这将是您为自己创建的自定义内容，除非您发布自己的规范，否则没有人会理解如何使用它。
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
谁说只有你一个人才能写出唯一的front-end？或者 back-end 永远不会移动到另一个平台？当这类东西有开放标准时，不要局限于定制某些东西。
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
没有。它们是帮助客户端和服务器以标准化方式相互通信的必需协议元素。
Authorization 是用于身份验证的标准 HTTP header。它有一个 type，因此客户端可以指定它使用的是哪种身份验证方案（Basic vs NTLM vs Bearer，等等）。重要的是客户端指定正在使用的正确方案，并且服务器只处理它识别的方案。
Bearer 是 OAuth 在 Authorization header 中使用的 type 身份验证。 access_token是OAuth的Bearer认证的参数。
如果您使用 Authorization header（您应该使用），您 必须 指定 类型 ，根据 RFC 2616 and 2617:
Authorization = "Authorization" ":" credentials credentials = auth-scheme #auth-param auth-scheme = token auth-param = token "=" ( token | quoted-string )
所以，在这种情况下，Bearer 是 auth-scheme 而 access_token 是 auth-param.
Are they analogous to coding-styles?
没有
Or is there any functional impact in not following the above guidelines?
是的。使用您的自定义身份验证系统的客户端将无法在任何遵循既定规范的服务器上进行身份验证。您的服务器将无法验证任何不使用您的自定义身份验证系统的客户端。