FHIR, Oauth2 and the Mobile client

原文链接:FHIR, Oauth2 and the Mobile client

FHIR和OAuth2中讨论了web应用程序(浏览器端运行 代码在服务器端)中最常见的流程，但如果是桌面和移动应用程序如何处理？要考虑以下几点：

• 对于应用程序而言，用户有哪些，是否需要存储刷新指令，
• 在OAuth2的处理流程当中，它是依赖HTTPS的。主要用在登录界面和浏览器重定向。

刷新令牌的处理

理论上，这些应用程序都不能安全地保存刷新令牌。原因在于该刷新指令将会存储在终端用户的移动设备或电脑上，黑客如果想获取该刷新指令是很容易的。这么讲的话，应用程序是不能存储刷新指令的。用户每次需要使用刷新令牌的时候，必须与授权服务器进行认证，这个session的生命周期与访问指令的生命周期一样长。事实上，针对这种情况，OAuth2描述了一种这样的特殊流程Implicit workflow,在用户认证通过之后授权服务器直接返回访问指令，但不会返回一个刷新指令。这是针对于用户不想要长期保存凭据的这种'公开式'场景.

这样是很好理解,但对于用户而言,如果是用户自己使用的移动设备的话,就不是那么友好.这种情况下,你除了需要在本地存储刷新令牌之外没有其他可选的解决方案:

• 你必须尽可能做到更安全.
• 你必须应对多用户使用的APP可能性,比方说与当前用户的关联
• 你必须提供一种简单的机制能够让用户废除访问令牌.标准本身并没有说明如何处理这种情况,一种方法是授权服务器会有一个重置或设备遗失的功能.当用户登录之后,会出现一个正常的web界面,授权服务器会撤销所有与用户相关的刷新指令.当用户使用新的设备时需要重新认证,整个流程正常继续.

以这种方式的话,也能够理解如何在桌面端和移动端应用程序使用OAuth2 一种方法是在应用程序中启动一个内嵌式的浏览器窗口来与授权服务器进行交互,如下图所示  

1. 用户以某种方式登录并启动了APP,APP调用浏览器组件并直接调用授权服务器的登录请求节点,授权服务器生成并返回一个登录界面.
2. 用户输入信息并将页面提交给授权服务器.授权服务器认证用户通过之后,生成一个认证码,发送一个重定向给内嵌式浏览器,浏览器会重定向至应用程序的回调节点
3. 应用程序拦截了内嵌式浏览器的重定向
4. 应用程序从中抽取出认证码并终止了浏览器组件
5. 应用程序发送一个HTTPS请求给授权服务器,认证码作为参数传输过去,服务器返回一个访问令牌和刷新令牌.
6. 以最安全的方式将刷新令牌保存在本地
7. 应用程序发送HTTPS请求给资源服务器,将访问令牌作为参数传递过去,资源服务器对访问令牌进行校验,通过之后则返回数据.
8. 应用程序完成其他的业务逻辑.

对于废弃的访问令牌如何处理,访问令牌都有自己的生命周期,但如果在处理过程中访问令牌失效了该怎么办.流程类似如下:

1. 应用程序向资源服务器发送请求.
2. 资源服务器发现令牌已失效,拒绝了这次请求 标准中并未对状态码进行描述,可能是401-Unauthorized
3. 应用程序从本地存储库中获取刷新令牌,将其发送给授权服务器.授权服务器再次向应用程序提供一个有效的访问令牌.
4. 应用程序利用新的访问令牌再次向资源服务器发送请求.

这篇文章描述了桌面端和移动端应用程序如何实现标准的OAuth2协议来对用户进行认证,授权用户访问数据.当然,这并不是唯一的方法,但是最直接最易于实现一种方法.

可以利用 开源库!来实现