让我们忘记一下你有一个AngularJS应用程序,并查看OpenID认证交换的工作原理：

>用户输入登录表单中的OpenID URL并提交给服务器
>服务器获取OpenID URL并通过重定向到OpenID提供程序进行响应.重定向包含一些参数,包括回调URL.
> OpenID提供商提示用户输入登录凭据,然后允许与服务器应用程序共享他/她的身份.
> OpenID提供商以步骤2中作为回调给出的URL将重定向重定向回到应用程序,并使用户可以使用ID,电子邮件,用户名等用户信息.
>服务器现在具有用户信息,可以通过唯一的ID,电子邮件地址或其他一些标识来将用户定位在自己的用户数据库中.此时,如果用户不知道应用程序,则可以创建一个新帐户.
>现在用户已知,服务器可以编写一个记录他/她的身份的cookie,但请注意,这与第5步中的身份不同.OpenID提供者返回的身份信息对于找到用户在您自己的数据库中,所以现在您可以在应用程序的上下文中记录用户的标识.这可能是数据库用户ID,电子邮件地址或用户名(如果它们是唯一的)或令牌,可以是您对用户的一些信息的哈希.
>写入每个发送到服务器的新请求的cookie都带有标识已验证用户的数据.

所以我们来看看当你添加AngularJS时会发生什么.请注意,有很多方法可以做到这一点,下面我描述的是一种可能性.

如果Angular应用程序向需要身份验证的服务器发出请求,则服务器应返回错误代码401.例如,当Angular应用程序获取401时,可以弹出登录表单.

但是,由于需要浏览器重定向,因此OpenID认证舞蹈无法在丰富的JS应用程序的上下文中完成.您的服务器端应用程序将至少支持三条路由：

>为Angular应用程序提供的根URL
>启动OpenID身份验证的URL
>作为回调发送到OpenID提供者的URL

因此,用户连接到您的根URL,并获取AngularJS应用程序,该应用程序以非验证状态启动.在某些时候,Angular应用程序将提示用户登录,使用具有OpenID文本字段的表单提交一个提交按钮.这些表单字段应该是发布到服务器的常规HTML表单的一部分,而不是附加到控制器的客户端角度元素.表单的“action”属性应指向服务器的OpenID登录路由.

当用户单击登录按钮时,服务器唤醒并接收启动OpenID认证的请求.此时上述步骤1-5运行没有变化.

在步骤5的最后,服务器将用户定位在应用程序的数据库中.服务器现在可以做的是通过重定向回到根URL,以便重新启动Angular应用程序.如果应用程序需要在不是初始状态的状态下重新启动,则在启动OpenID身份验证过程之前,可以将客户端存储(例如,Cookie)保存到恢复状态.

但是这还不够,服务器还需要传递一些关于登录用户的信息.一种方法是将用户的唯一ID或令牌附加到重定向URL的查询字符串中,Angular应用程序可以访问.这将是上述步骤6中进入Cookie的同一张ID.

现在Angular应用程序重新启动,如果需要,可以恢复其状态,并具有识别登录用户的ID或令牌.当应用程序需要向服务器发出Ajax请求时,会将该ID或令牌与请求一起发送.服务器可以验证它并返回401,如果发现它是无效的或者如果它有一个到期日期,并发现已过期.

如果与请求一起发送的标识被验证,则可以执行请求,并且可以将响应发送回Angular应用.

可以在客户端通过删除用户ID /令牌来实现注销功能,以便将来再次发送对服务器的请求而不进行验证.

非常重要：Angular应用程序和包含用户信息的Flask服务器之间的所有交换都必须通过安全的HTTP来完成.如果不是您的ID或令牌将以纯文本行进.