为Web应用程序使用自己的API - 使用OAuth2进行身份验证过程

Question

概观

我目前正在为图像共享应用程序创建一个API,该应用程序将在网络上运行,并在将来的某个时间在移动设备上运行.我理解API构建的逻辑部分,但我仍然在努力满足自己对身份验证部分的要求.

因此,我的API必须是全世界都可访问的:具有访客访问权限(例如,未登录的人可以上载)以及注册用户.因此,当注册用户上传时,我显然希望将用户信息与请求一起发送,并通过我的数据库中的外键将该用户信息附加到上载的图像.

---

通过OAuth2进行身份验证 - 实施

我已经明白OAuth2是API身份验证的方法,所以我要实现这一点,但我真的很想知道如何处理我的情况.我想到使用client credentials授权并为我的Web应用程序仅生成一组凭据,并让它向API发送请求,client secret以获取访问令牌并让用户执行操作.用户注册过程本身将使用此授权进行处理.

但是当用户注册并登录时呢？我现在如何处理身份验证？这是否需要另一笔补助金来接管？我在考虑在用户登录期间进行一些授权过程,以生成新的访问令牌.这种方法有误吗？

---

我需要帮助的是什么

我需要你的输入如何正确处理我的情况下的身份验证流程.这种双向身份验证过程可能不是我需要的,但它是我理解它的方式.我非常感谢您的支持.

Answer 1

你的方法似乎可行.

Oauth2有4个主要部分:

• 资源服务器(您的API)
• 资源所有者(在资源服务器上有数据的最终用户)
• 授权服务器(获取授权和签发令牌)
• 客户(您的网络应用 - 以及未来的应用)

请记住使用客户端凭据授予,您发出的令牌可能没有任何用户上下文.因此,如果您的API端点依赖于令牌中包含的用户标识符/资源所有者,那么您将需要为此类型的令牌编写代码.

如果您确实需要令牌为您的API拥有一些资源所有者上下文,并且您的Web应用程序恰好是您的身份提供者,那么您可以使用资源所有者密码授予,它将在上下文中为您提供令牌和刷新令牌.资源所有者/用户.

该授权码补助,提供优良的未来API消费者Web应用程序(即在服务器上运行).如果您计划允许移动/本机应用程序使用您的API,那么您应该考虑在授权服务器中允许隐式授权.

如果您的API没有最终用户,并且每个客户端具有不同的API访问权限,具体取决于它是什么应用程序,那么您可以使用客户端凭据授予并使用范围来限制API访问.

编辑

因此,我的API必须可供访客访问(例如,未登录的人员可以上传)和注册用户访问.因此,当注册用户上传时,我显然希望将用户与请求一起发送并将该用户附加到上传的图像

为实现此目的,您的API上传端点可以处理Oauth2.0承载令牌,但不依赖于它们.例如,任何人都可以使用端点,并且在标头中提供访问令牌的人将使其上传与API从令牌中获取的用户上下文相关联.然后,如果需要,您可以使其他端点依赖于令牌.

根据评论编辑

注册过程本身会使用客户端凭据授权,对吗？

我不认为注册过程本身应该是Oauth保护的资源.理想情况下,注册应由您的身份提供商处理(例如谷歌,脸书或您自己的用户会员数据库).关于Oauth2.0的另一个优点是,它不需要API来执行用户管理工作.

Answer 2

您真的不需要oauth来验证您自己的API.

如果您希望其他应用程序访问您的API,OAuth2非常有用.

让我解释一下OAuth2的工作原理:

• 客户端(应用程序)想要使用您的API,因此您可以为其提供客户端凭据(client_token和client_secret).并在数据库中设置一组客户端可以使用的重定向位置.
• 客户需要用户授权才能代表用户使用您的API.因此,客户端向用户发送一个URL在您的网站(与client_token,范围,客户端需要[您定义的不同范围的含义],重定向URI和RESPONSE_TYPE [OAuth2用户定义不同的RESPONSE_TYPE但让我们专注于"代码"])
• 用户登录您的站点并接受代表用户访问您的API的客户端.当用户接受此权限时,您将生成一个授权(授权包含用户的信息,请求的凭据[范围]以及可以"声明"授予访问权限的客户端).
• 然后,用户被重定向到客户端请求的redirect_uri(当客户端将用户发送到您的auth站点时),并且在URL参数中,您将包含授权代码(它只是一个id).
• 在这个阶段,客户端将让你的API提供的补助金码,自己client_token,他client_secret和grant_type(authorization_code)的请求,他将得到的回应如下:一authorization_token,refresh_token,token_type(这种情况,Bearer),expires_in(以秒为单位的到期时间)和范围.
• 完成所有这些后,客户端将能够代表用户使用access_token进行API请求,直到令牌过期.一旦令牌过期,客户端将不得不使用refresh_token(而不是授权码)请求新的access_token.

Answer 3

iandayman的答案有很多很好的信息,但我认为更狭隘的更具体的答案可能会对你有所帮助.

因此对于初学者来说,客户端凭据授权不适合您.如果我们查看OAuth2规范,则客户端凭据授权适用于

当授权范围仅限于客户端控制下的受保护资源时...当客户端代表自己行事时

出于两个原因,这不适合你.
首先,您的客户无法控制受保护的资源.您访问的所有资源都是不受保护的(未登录人员上传)或受最终用户控制.此外,您无法在浏览器中保留机密(例如客户端机密); 您的应用程序的任何用户都可以使用浏览器的开发人员工具来查看和破坏秘密.
其次,正如我所提到的,客户永远不会代表自己行事.它始终代表可能登录或未登录的用户.

您希望资源所有者密码凭据授予.
当用户未登录时(就像您上传的那样),您只是没有授权.用户登录时,将其凭据发送到授权服务器.如果密码与用户名匹配,则授权服务器生成令牌并持久保存从该令牌到用户的映射并返回令牌.然后,每次客户端向登录用户发出另一个请求时,都会将该令牌放入Authorization标头中.在后端,你会说"如果授权标题中有一个令牌,找出它对应的用户,并将它们与此上传相关联(或检查它们是否允许上传)".

用户注册如何工作？很简单,你发布一些像这样的用户对象

name: jim beam
username: jimb
password: correct horse battery staple

到您的用户创建端点(POST /users或某事).生成salt并哈希密码,然后将用户的信息与salt和hash一起存储在数据库中.此端点无权授权.

希望这更像是你在寻找的东西.