相关疑难解决方法(0)

我开发了一个单页应用程序原型,它在前端使用Backbone,并在服务器上使用瘦RESTful API来获取它的数据.

来自繁重的服务器端应用程序开发(php和python),我非常喜欢使用胖客户端MVC的新的不同设计方法,但我对如何最好地将应用程序限制为登录的经过身份验证的用户感到困惑.

我更喜欢将应用程序本身放在登录后面,并且除了站点的本机登录之外,还希望最终实现其他类型的登录(openid,fb connect等).我不清楚这是如何完成的并且一直在搜索 - 但是在找到让我清楚的信息方面不成功.

总体而言,目前注册用户并要求他们登录以使用您的单页应用程序的最佳做法是什么？

用户登录后,api请求如何进行身份验证？我可以存储会话但是如何在API调用中检测此会话,或者我是否需要在每次单独的API调用中传递一个令牌？任何答案都将非常感谢!

几天来,我一直在为单页面应用程序寻找安全的身份验证和会话管理机制.从有关SPA和身份验证的众多教程和博客文章来看,将JWT存储在localStorage或常规cookie中似乎是最常用的方法,但将JWT用于会话并不是一个好主意因此它不是这个应用程序的选项.

要求

• 登录应该是可以撤销的.例如,如果在用户的帐户上检测到可疑活动,则应该可以立即撤消该用户的访问权限并需要新登录.同样,密码重置等操作应撤消所有现有登录.
• 身份验证应该通过Ajax进行.之后不应该进行浏览器重定向("硬"重定向).所有导航都应该在SPA内部进行.
• 一切都应该跨域工作.SPA将在www.domain1.com上,服务器将在www.domain2.com上.
• JavaScript应该无权访问服务器发送的敏感数据,例如会话ID.这是为了防止XSS攻击,其中恶意脚本可以从常规cookie,localStorage或sessionStorage中窃取令牌或会话ID.

理想的机制似乎是使用HttpOnly包含会话ID的cookie进行基于cookie的身份验证.流程将如下工作:

1. 用户到达登录页面并提交其用户名和密码.
2. 服务器对用户进行身份验证,并将会话ID作为HttpOnly响应cookie 发送.
3. 然后,SPA在随后向服务器发出的XHR请求中包含此cookie.这似乎可以使用该withCredentials选项.
4. 当向受保护的端点发出请求时,服务器会查找cookie.如果找到,它会将该会话ID与数据库表进行交叉检查,以确保会话仍然有效.
5. 当用户注销时,会话将从数据库中删除.下次用户到达站点时,SPA会收到401/403响应(因为会话已过期),然后将用户带到登录屏幕.

因为cookie具有HttpOnly标志,JavaScript将无法读取其内容,因此只要通过HTTPS传输,它就不会受到攻击.

挑战

这是我遇到的具体问题.我的服务器配置为处理CORS请求.在对用户进行身份验证后,它会在响应中正确发送cookie:

HTTP/1.1 200 OK
server: Cowboy
date: Wed, 15 Mar 2017 22:35:46 GMT
content-length: 59
set-cookie: _myapp_key=SFMyNTYBbQAAABBn; path=/; HttpOnly
content-type: application/json; charset=utf-8
cache-control: max-age=0, private, must-revalidate
x-request-id: qi2q2rtt7mpi9u9c703tp7idmfg4qs6o
access-control-allow-origin: http://localhost:8080
access-control-expose-headers: 
access-control-allow-credentials: true
vary: Origin

但是,浏览器不保存cookie(当我检查Chrome的本地cookie时,它不存在).因此,当以下代码运行时:

context.axios.post(LOGIN_URL, creds).then(response => {
  context.$router.push("/api/account")
}

并创建帐户页面:

created() {
  this.axios.get(SERVER_URL + "/api/account/", {withCredentials: true}).then(response => {
    //do stuff
  } …

将通过身份验证调用返回的API令牌存储在Flux(特别是Redux)存储中是否安全？我已经使用Webpack来编译项目中的所有资产,我相信这意味着商店的范围远离第三方脚本,这些脚本希望读取商店并提取令牌.

并且,为了它的价值,令牌通过HTTPS在Authorization: bearer ...标头中发送.

您知道,Web应用程序需要会话或cookie来进行身份验证.我尝试使用Vue.JS和Flask微框架构建Web应用程序,例如ERP或CRM.

我糊涂了.我如何处理会话？我们认为我们在Flask中有这样的代码:

import os
from flask import Flask, request, jsonify, abort, session

app = Flask(__name__)
app.config['SECRET_KEY'] = os.getenv('SECRET_KEY') or \
    'e5ac358c-f0bf-11e5-9e39-d3b532c10a28'

@app.route('/login', methods=['POST'])
def user_login():
    user = request.form['user']
    session['isLogged'] = True
    return jsonify({'status': session['isLogged']})

@app.route('/user-info')
def user_info():
    if 'isLogged' in session:
        return jsonify({'user': 'ali'})
    else:
        return jsonify({'error': 'Authentication error'})

我们的前端代码应该是这样的:

  mounted() {
    this.checkIsLogged();
  },
  methods: {
    checkIsLogged() {
      fetch('http://127.0.0.1:5000/user-info', {
        mode: 'no-cors',
        method: 'GET',
      }).then((resp) => {
        return resp;
      }).then((obj) => {
        if(obj.user) {
          this.status = true
        }
      })
    }, …

由于目前没有适用于 SvelteKit 的 Auth0 SDK，因此当我打算将 Auth0 合并到我的 SvelteKit 应用程序中（包括服务器端身份验证）时，我正在学习（或至少尝试学习）有关身份验证的知识，这比我最初的意图要多得多。该文档有点令人困惑（或者可能它只是很大，或者可能我只是不那么聪明），所以我希望在这里描述我的身份验证流程以供批评（希望这对将来的其他人有帮助） ）。

我已经阅读了这篇关于 SPA auth以及Auth0 教育产品的精彩文章。但我仍然不确定我是否正确地将这些点连接起来。这是我的流程。所有这一切仅通过 SSL 发生。

\n
1. 我使用他们的客户端 SDK ( @auth0/auth0-spa-js )在客户端创建一个 Auth0 客户端。该客户端通过 Auth0 弹出窗口执行身份验证。
\n
2. 一旦通过身份验证，一切都会在客户端按预期运行。但如果我想在服务器端控制对路由的访问，我需要将信息返回到服务器。所以...
\n
3. 身份验证后，Auth0 创建一个 ID 令牌（签名的 JWT），该令牌存储在浏览器的本地存储中。我将其保存为会话 cookie（SameSite=strict; HTTPOnly; Secure;设置了选项），以便它通过路由授权请求传递回服务器。
\n

所以让我在这里暂停一下...我明白（至少根据一些内容，包括上面链接的 Auth0 教育视频）ID 令牌不应该用于身份验证，并且永远不应该被传递。这就是访问令牌的用途。然而，在这种情况下，交换都是第一方（我的客户端，我的服务器），我的理解是“可以”。

然而，Auth0 SDK 本身并没有设置 cookie，这确实让我感到紧张。这让我怀疑我是否做错了\xe2\x84\xa2。

\n

4. 在服务器上，我使用公钥验证 id_token，然后可以根据需要在后端保存用户详细信息等，并允许访问适当的路由（hooks.server.js在我的 SvelteKit 应用程序中通过）。

   \n
\n

5. 当用户注销或令牌过期时，cookie 将被删除。

   \n
\n

（顺便说一句，我还没有弄清楚如何在 ID 令牌过期时刷新它，因为 Auth0 客户端 SDK 似乎永远不会更新浏览器存储中的 ID 令牌，即使它已过期。）