我们有我们的申请（App-A）由企业A构建，需要使用第三方IDP（Ping身份）来联合用户身份验证。除了允许用户通过Ping进行身份验证以登录我们的App-A之外，我们还需要允许由另一个Enterprise-B构建的App-B代表我们的用户访问有关他们的信息（离线访问），一旦我们的用户验证进入我们的系统，并提供所需的同意。显然，OpenID连接与授权代码流似乎是要走的路。
现在，当用户直接登录到我们的App-A时，以及当用户通过App-B并向App-B提供offline_access同意以便他们从App-A访问用户的信息时，“我们有一个要求”，即身份验证页面需要完全自定义并主题化为我们的App-A的产品主题/颜色。
App-B（Enterprise-B）还要求我们或我们的IDP托管一个“/.well-known/openid-configuration”端点，其中列出了authorization_endpoint、token_endpoint、userinfo_endpoint、scopes_supported（包括offline_access作用域）以及其他内容（如OIDC标准）。
现在我的问题是，当App-B将用户重定向到我们的App-A，并同意允许App-B从App-A访问他们的信息时，我知道App-B会将用户重定向到“/.well-known/openid-configuration”端点中的“authorization_endpoint”所指向的URL，以挑战用户进行身份验证。
a）我们的IDP（Ping身份）是否应该为我们构建自定义登录屏幕和同意屏幕，或者b）我们是否可以构建此自定义主题登录屏幕，在成功进行身份验证和同意后，可以从IDP向App-B返回authorization_code？
P.S：我们的前端（在App-A上）是一个Angular SPA，通过电容器封装，在Web、iOS和Android上运行。我们的后端（资源服务器）作为REST API提供，可以通过IDP对access_token进行JWT验证。
1条答案
按热度按时间smdncfj31#
在这里，我想从所有权的Angular 更清楚地说明角色：
组件角色（企业A）
企业A使用授权服务器（AS）来保护其数据：
然后，来自企业A的API可以正确地授权，因为所发布的令牌及其范围和声明由企业A控制。
组件角色（企业B）
这些应与企业A的相同，并应用于应用B及其API。
认证
授权服务器也具有IDP功能。以下是一些示例：
实现这一点的一种方法是将AS A配置为提示输入用户标识符（如电子邮件），然后它可以查找用户的企业，然后重定向到相应的IDP以验证用户。
答复
这听起来可能很复杂，但这是一个功能强大的行为，不需要任何代码。我总是建议从API需要的东西开始反向工作，因为OAuth主要是保护数据，而不是身份验证。