【发布时间】：2018-01-23 08:42:39
【问题描述】：
谁能指出我配置 jhipster 网关以使用外部 OpenID Connect (OIDC) 提供程序而不是捆绑所有 UAA 东西的方向？我知道 jhipster UAA 服务器，但这似乎是一个独立的身份验证服务器。
我的用例是我的（许多）不同的 jhipster 微服务项目将由外部 OIDC 提供商处理其身份验证和 JWT 生成内容，而不是 jhipster 网关本身。
顺便说一句，我知道这些项目：
github.com/jhipster/jhipster-openid-connect
github.com/sdoxsee/jhipster-openid-connect-microservices
我已经阅读了这个冗长的讨论，似乎得出的结论是，OpenId Connect 替代方案正在酝酿之中： https://github.com/jhipster/jhipster-experimental-microservices/issues/3
我有一些想法：
设置微服务堆栈以使用 UAA 服务器。然后，以某种方式，而不是使用 jhipster UAA 服务器，而是指向我的外部 OIDC 提供程序。
看看mraible对to the Stormpath (and soon to come Okta) subgenerator做了什么。
使用“社交登录”进行实验 (jhipster.github.io/tips/012_tip_add_new_spring_social_connector.html)
有人愿意讨论吗？
【问题讨论】：
-
完全同意这个。我认为主要问题是 jhipster 使用的用户域模型几乎总是与身份提供者使用的不同。您需要将您的提供商的用户模型调整为 jhipster 模型。有一些表示提供者支持的用户模型（例如 scim）的标准方法。也许 jhipster 应该采用 scim 来使这更容易。
-
另一个问题是要生成什么流。隐式、混合或授权代码流。我想我倾向于只支持一个流程——即授权代码流程，因为我们不能支持所有流程，它将令牌安全地保存在服务器端，并且可以利用 spring 的 SSO 功能
-
感谢 SCIM 的提示，我不知道 :) 我喜欢这些标准。至于支持哪个流：授权码流至少应该是默认流。
-
看youtube.com/watch?v=72K7cMCv7eM&t=1844s（大约：17:40）Matt 正在谈论他们在 Okta 开发的一个库：Juiser，它处理 jwt 和用户对象之间的转换
-
至于查看 Juiser，这可能是一个不错的起点：developer.okta.com/blog/2017/08/08/secure-spring-microservices
标签： jhipster spring-cloud openid-connect