阅读最新的 OAuth2 草案后，我不确定哪种流程适合我正在开发的客户端，或者 OAuth 是否完全合适。我们的 API 提供的数据并不特定于某个用户；拥有凭据只是授予用户访问我们数据的权限。
我正在构建的 JS 客户端将是一个不需要用户进行身份验证的公共(public)页面。相反，“用户”是 JS 客户端本身。也就是说，有一个专门的帐户专门供该应用程序访问我们的 API。
目前，我只是添加一个带有 HTTP Basic 凭据的 Authorization header ，但由于多种原因，这很糟糕。最重要的是，任何人都可以轻松提取用户名和密码。
我在 OAuth 草案中看到的与此场景最接近的匹配是隐式授权授予，但操作用户代理(Web 浏览器)的人似乎仍然必须与页面交互才能获取访问 token 。比如说，必须单击一个按钮，然后往返于身份验证服务器，然后返回 JS 客户端(通过 redirect_uri)，这是不合适的。
另一方面，如果无法使用私钥(因为它是 JS)，我无法想象如何在不使用 redirect_uri 的情况下验证客户端。
有人可以纠正我吗？
最佳答案
访问 token 将传递到 url 片段中的redirect_uri。您可以通过解析window.location.hash值来获取。
On the other hand, without being able to use a private key (because it's JS), I can't imagine how the client could be verified without using the redirect_uri.
隐式授权类型不会对客户端进行身份验证。在某些情况下，可以通过用于将访问 token 传递给客户端的 redirct_uri 来验证客户端身份。它依赖于资源所有者(其凭据)的存在和重定向 URI 的注册。此流程中需要redirect_uri。有些 SDK 说它是“可选的”，因为它们有一个默认配置，通常与 API 服务所在的域相同，或者在资源提供者上预先配置。
关于javascript - 适用于 JavaScript API 客户端的适当 OAuth2 流程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8101468/