Open ID Connect和原生公共应用程序......没有隐含流,没有混合流......那么什么？

Question

我们目前正在开发本机移动应用程序,我们需要使用我们的身份服务器(由thinktecture身份服务器v3制作)和/或外部社交身份提供程序对最终用户进行身份验证,以消耗我们系统中的一些资源.

我们正在尝试使用OIDC来获取访问令牌和ID令牌.在一个完美的世界中,我们希望本机移动应用程序最终用户无限期地保持记录(甚至跨本机应用程序重新启动),直到最终用户决定注销.

首先,我们选择了隐式流程.但我们发现此流程中没有刷新令牌.

1.为什么隐式流量规范禁止刷新令牌？危险在哪里？

换句话说,为什么令牌端点不具有隐式流"可达"？

然后,我们测试了混合流以获得刷新令牌(非常长寿但可撤销)和访问令牌(短期).问题是将client_secret嵌入到本机公共客户端中.(OIDC规范描述的不良和不安全的做法)

3)所以...本地公共应用程序不能使用混合流...嗯？

所以,我们现在想知道自定义代码流解决方案是否是一个好主意:创建一个"代理"/"前端"web api,它可以使用自己的安全client_secret到达令牌端点,因此,转发代码/ refresh_token/access_token请求从本机客户端应用程序到授权服务器令牌端点？

自定义代码流图

4)对此有何评论？

Answer 1

OAuth 2.0已隐补助,主要目的是为在浏览器客户端的优化过的授权码保佑,不能让客户端机密,因此可以假设这些客户也不能保证的刷新令牌一个秘密,在至少重新启动,因为挑战是相同的.

您可以使用授权代码授权并将您的本机移动应用程序注册为公共客户端,即它不会有客户机密,只是注册redirect_uri.

请注意,刷新令牌与用户登录无关,也不用于刷新用户登录状态.您只能使用它来获取新的访问令牌以代表用户使用/操作.在初始收到id_token与授权服务器(AS)或任何令牌(access_token/ refresh_token/ id_token)上的用户状态无关的用户之后,您可以决定将用户永远记录为仅在应用内登录的决定.如果您想要考虑AS的登录状态,您可以发送带prompt=none参数的授权请求,并检查授权响应中的id_token或错误.