这对于sinatra + angular.js +自定义提供程序的Oauth2工作流的概念是否正确?
我想构建三个示例应用程序。 一个是sinatra oauth2提供者,第二个是rails应用程序,前端是angular.js,后端是rails,第三个是后端的sinatra和前端的angular.js。
我们的Rails / Sinatra应用程序将使用satelizer和我们的自定义提供程序对用户进行身份validation。
这些是我们现在的Oauth2工作流程。
- 使用Satellizer,我们从提供商处获取授权码。 我们将此代码发送到我们的后端。
- 在使用此授权码,密钥和其他参数的后端,我们向提供商发送请求以获取访问令牌。
- 使用此获取访问令牌,我们调用
'/me'
操作以从提供者获取uid,电子邮件和其他用户属性。 - 在同一个操作中,我们解析响应主体,并根据uid查找或创建用户。
- 我们想知道这个步骤应该以某种方式设置用户的身份validation令牌。
- 将提供者访问令牌存储在用户数据库记录中。
- 生成新的身份validation令牌并在每个请求上更改它
- 使用用户uid和令牌生成JWToken并将其发送回卫星器。
- 然后在每个请求上, Satellizer在标头中包括Bearer JWToken 。 在recive请求我们的后端validation存储在数据库中的标头令牌并在我们的案例
devise(sign_in, store: false)
调用sing_in方法devise(sign_in, store: false)
可能在sinatra app中我们将使用warden。
您如何看待这个概念? 也许我们错过了什么。 这是我们的第一个oauth2身份validation实现,我们对此感到担忧。