移动应用+ REST后端中的OpenID Connect身份验证流程(使用KeyCloak)

时间:2017-06-22 08:18:17

标签: rest authentication mobile oauth openid-connect

我想使用OpenID Connect保护移动应用的REST后端。简而言之,应用程序的用户应在通过REST后端(多个服务)获取敏感数据之前对自身进行身份验证(用户名/密码)。

在初始身份验证之后,他们应该会收到一个ID /访问令牌,然后他们可以在其应用会话的剩余时间内用于服务通信。获取此ID令牌非常重要,因为它包含后端所需的信息。

作为实现此方案的Identity Provide,我想使用KeyCloak。但是,我不确定要实现的最佳身份验证流程。我阅读了thisthis stackoverflow帖子,但我仍然不确定我所需的解决方案是否有效/安全/可接受。

从我读到的关于openID Connect的内容来看,推荐的openID Connect auth流程是“三条腿授权代码流程”,其中涉及:

  1. 将用户重定向到Identity Provider的登录页面(在我的案例中为KeyCloak)进行身份验证(例如登录表单)。
  2. 成功验证后,IP会将用户重定向回应用程序以及作为请求参数传递的身份验证代码。
  3. 然后,应用程序可以通过将此身份验证代码传递给“标准化”令牌端点来从IP获取id / acccess令牌。
  4. 对于基于浏览器的Web应用程序来说,这一切听起来都很好,但在我们的应用程序中,我们希望避免使用外部登录页面,而是拥有一个“本地”应用程序内登录页面,以免过多地破坏用户的体验。此外,我们的应用程序有一个功能,让您“登录”。在这种情况下,用户只登录一次,然后应用程序在启动时在后台获取所有令牌。

    因此,根据我们的要求,我发现了this博客文章,该文章使用了一种双腿资源所有者凭据流方法,该方法允许应用程序对自身进行身份验证并在一个用户中收集令牌请求,无需导航到keycloak登录页面。

    我对此进行了测试,此解决方案似乎提供了我们所需的功能。此外,在我们的案例中,app和KeyCloak(=自发布的OpenID提供商)仅在内部使用,属于同一法人实体。

    在我们的使用案例中,是否允许使用双腿方法,如果没有,为什么不呢?这种方法是否会带来一些安全风险,而这种风险并不适合三方法?

    我真的希望听到你们的意见!

    更新16-10-2018:哇,伙计们,我从Nate Barbettini找到了一个非常有趣的教程演示文稿(https://www.youtube.com/watch?v=996OiexHze0),内容包括oauth,openid connect和认证流程的类型在非常明确的条件下,但也非常深入。在使用ouath / openid connect进行复杂的授权/身份验证之前,我建议所有人都要先查看这些信息。

    此致

    金 荷兰

2 个答案:

答案 0 :(得分:1)

我相信除非真正需要 const zoom = d3.zoom() .on('zoom', () => { const t = d3.event.transform; x.domain(t.rescaleX(x2).domain()); y.domain(t.rescaleY(y2).domain()); render(); }); const yAxisZoom = d3.zoom() .on('zoom', () => { y.domain(d3.event.transform.rescaleY(y2).domain()); render(); }); const yAxisDrag = d3.drag() .on('drag', () => { const factor = Math.pow(2, -d3.event.dy * 0.01); d3.select('#zoom-chart .plot-area').call(yAxisZoom.scaleBy, factor); }); 流程,否则客户端应用和环境应完全由您自己控制。您可能对应用程序拥有完全控制权,但无法控制手机操作系统(安全更新,...)

blog post解决了各种问题。我并不完全同意该帖子中提到的所有观点,但我引用了一些相关的观点:

  • 面对OAuth最佳做法指南(RFC8252)
  • 公共客户端应用程序无法保存机密,因此无法对其进行身份验证
  • 大大增加了用户凭据的攻击面(如果客户端受到攻击,用户的整个帐户也会受到攻击)

这也是奥赖利(O'Reilly)的书Getting Started with OAuth 2.0 by Ruan Boyd的摘录:

何时应使用资源所有者密码流? 由于资源所有者的密码已公开给应用程序,因此此流程 应该谨慎使用。仅建议第一方 由API提供者发布但未打开的“正式”应用程序 到更广泛的第三方开发者社区。

如果要求用户将密码输入“官方” 应用程序,他们可能会习惯于这样做并成为 容易受到其他应用程序的网络钓鱼攻击的攻击。为了减轻 对于这种担忧,开发人员和IT管理员应该明确地进行教育 他们的用户应该如何确定哪些应用是“官方的”,以及 不是。

答案 1 :(得分:0)

以下链接节省了我很多时间。 https://developers.redhat.com/blog/2020/01/29/api-login-and-jwt-token-generation-using-keycloak#set_up_a_client

我认为最重要的是

<块引用>

填写客户表单中的所有必填字段。请注意, 特别是,直接授予流(如图 6 所示)并设置其值 直接授予。此外,将访问类型更改为机密。

以及我们必须将凭据发送到其中以进行验证的 URL。

 ajax: { 
   ...
   data: fundtion(d) {
     d.court_date_id = courtDateSelected;
     d.checked_in = 'true';
   }
   ...