小编Kav*_*uwa的帖子

我们的项目由几个子应用程序组成，我们正在寻找一种解决方案来实现 SSO 以避免对每个子应用程序进行身份验证。

假设这是我们项目的结构：

authentication server(call it AS or IdP or something else)
order-system
product-system
data-analysis-system
.......

而且我们发现，有很多的文章“SSO实现了基于OAuth2用户”喜欢这样。

在那篇文章中，我们更喜欢该SAML策略，因为它简单明了，但是对于原生应用程序有一些限制，然后我们重点介绍了 OAuth2。

这是工作流程：

1 OAuth2 中的规则

资源服务器 (SP) – 这是您尝试访问信息的网络服务器。

客户端——这是用户与资源服务器交互的方式。这可以是基于浏览器的 Web 应用程序、本机移动应用程序、桌面应用程序、服务器端应用程序。

授权服务器 (Idp) – 这是拥有用户身份和凭据的服务器。它是用户实际进行身份验证和授权的人。

以OctoDroid为例，规则是非常明确的：

Client: OctoDroid
Idp: GitHub
SP: Github
User: one who use OctoDroid application.

工作流程是OctoDroid( Client) 要求您( User) 登录并通过Github( Idp)授予权限以从Github( ) 获取资源(repos,issues SP)。

但是在我们的应用中，每个子系统究竟可以处理什么？一个SP或一个Client？

如果将其视为SP，是网络浏览器Client吗？我一直认为 aClient应该是一个应用程序。另外子系统每次请求都会通过Idp验证access_token，然后返回相关资源，这样会不会增加Idp的压力？ …

我们考虑使用 OpenID Connect 和 ID 令牌来对我们的公共 API 进行身份验证。

这些是我们想要涵盖的使用场景：

1. Web UI（单页、客户端 JavaScript 应用程序）
2. 交互式会话中使用的命令行界面 (CLI)
3. CLI 非交互式使用，例如在 CI/CD 管道中
4. 在非交互式会话中执行的其他 API 调用

(1) 和 (2) 的想法是使用 OIDC 隐式授权类型，以便用户在我们的 OpenID Connect 身份提供商处进行交互式身份验证（用户名/密码），并允许 RP（依赖方、客户端）访问用户身份。然后，身份提供者将向 RP 颁发一个短期 ID 令牌、一个刷新令牌和（可选？）一个访问令牌。

对于（3）和（4），交互式认证是不可能的。相反，我们希望向用户颁发令牌，允许他们代表自己访问我们的 API。这些令牌应该是长期存在的，只有当它们在系统中被删除时才会失效。

尽管如此，我们还是希望使用 JWT 就像身份提供者颁发的 ID 令牌一样，作为内部所有 API 请求的身份信息的载体。

我的问题是：

• 可以纯粹使用 OpenID Connect 隐式授权类型颁发的令牌之一来完成此操作吗？
• 访问令牌是否可以以长期有效（没有过期，仅通过从系统中删除而失效）的方式颁发，然后由客户端与 ID 令牌进行交换？
• 或者刷新令牌正是用于此目的的东西？
• 或者我们是否必须在 OpenID Connect 之外解决这个问题？这就留下了一个问题：如何根据身份详细信息 (JWT) 解析 API 请求中的不透明令牌，以便在我们的 API/服务中使用？

我想在 iOS 应用程序中通过 OpenID-Connect 实现登录。AppAuth-SDK 似乎是这样做的标准方法。下载一些示例后，我有点困惑。所有 AppAuth 示例和教程都使用 WebView，用户在其中输入用户名和密码。我想制作一个本机登录屏幕，用户必须在其中输入用户名和密码。AppAuth 是否可以做到这一点？我读到了一些关于“资源所有者密码授予”和“客户端秘密”的内容。这就是我需要的吗？

如果有人能把我推向正确的方向，我将非常感激。