基于OpenID Connect的插件Architecutre

时间:2016-05-23 10:42:13

标签: openid-connect identityserver3

在我们的系统上实现了出色的IdentityServer3之后,我们想向第三个开发者开放我们的平台。假设我们让开发人员在认证进度之后进入,即我们创建了IdentityServer客户端引用。

现在我们希望我们的用户在她的平台上“安装”一个应用程序。她进入某种商店并点击应用程序中的安装。在这里,我们想要启动一个OpenID连接流程,为开发人员提供一个允许他代表用户操作的访问令牌。

我已经考虑过这个流程,以实现这个目标:

  1. 点击“安装”后,我们通过指示应用程序中的重定向uri来启动流程
  2. 如果用户授予访问权限,则会将其重定向到我们的重定向uri。 Auth服务器为我们提供了代码
  3. 我们将代码发布到开发人员在客户注册过程中提供的原始Redirect Uri(由我们监督)
  4. 使用此代码及其client_id和client_secret的客户端将联系令牌端点(和我们的redirect_uri)并获取access_token(最终获得refresh_token)
  5. 这是一个安全的过程吗?我是这么认为的,因为客户端有client_id / client_secret来获取代码,甚至拦截代码的用户也无法获得Access令牌,因为他不知道client_secret。此流程让我的应用程序(托管商店的应用程序)确保安装了应用程序(即用户已授予访问其数据的权限)。

    现在,让我们假设这个流程在某种程度上是正确的。安装应用程序后,用户可能需要配置一些内容。

    在我们的应用程序环境中,我们加载iframe以打开app开发人员提供的配置页面。用户确定登录(因为她正在使用我们的应用程序),因此当加载iframe时,应用程序启动OpenID Connect流程(获取id_token并验证我们的用户)。在我看来这是一个简单的过程,但现在发生了一些奇怪的事情:即使已经同意,用户也会通过Auth Server提供新的同意屏幕。有人能理解为什么会这样吗?

    谢谢, 马可

1 个答案:

答案 0 :(得分:0)

关于返回同意屏幕上的问题,问题出在"离线访问"范围。要求此范围需要再次同意,即使用户已经提供了它。 发现于:https://github.com/IdentityServer/IdentityServer3/issues/2057