我们有一个使用 SprintBoot 和嵌入式 Jetty 服务器的 Java 8 后端应用程序。
应用程序的 UI 是使用 React 构建的单页应用程序。
目前，我已使用 spring security SAML 扩展与 Okta 集成来启用身份验证。当 Okta 将断言发布到我的应用程序时，我创建一个 session ，并在 cookie 中发送 JSESSIONID。
直到现在，当我们有一个非常简单的 UI 提供很少的 UI 组件时，这一切都很好。
但是，现在我们的后端有多个 REST 端点，我们也希望它们能够进行身份验证。 REST 端点本身是使用 Jersey 开发的。
如果我理解正确的话，SAML 显然不是基于纯 REST 的端点的选择，因为 SAML 主要是基于浏览器的协议(protocol)。这些 REST 端点也将由我们的 UI 调用，我们希望通过 Postman 或其他东西独立调用它们以进行测试。
当客户端调用这些 REST API 时，我猜测客户端应该发送一个授权 header ，该 header 应该由后端的身份验证过滤器之一进行检查。验证客户端和用户后，过滤器应将用户信息注入(inject)到 SecurityContext 中，因为 Jersey 会在所有 REST 端点中注入(inject) SecurityContext。然后从这个 SecurityContext 中获取用户就变得更容易了。
经过阅读，Okta OpenID Connect 似乎是发布 JWT 的一种选择。但是我不清楚如何使用它。也就是说，当 Okta 发出 JWT 时，我们的 UI 或任何客户端是否应该继续将授权 header 中的 JWT 发送到我们的 API，然后我们的 API 又应将 JWT 发送到 Okta 来验证它？
问题是，服务 UI 登录和 session 以及验证 REST 端点的最佳选择是什么？更不用说 REST API 本质上是无状态的。
最佳答案
When a client would call these REST APIs, I am guessing the client should send an Authorization header which should be checked by one of the authentication filters in the backend
在 OpendID Connect (OIDC) 中，授权 header 中的值是 id_token，可以采用 JWT 格式。此 id_token 由 OIDC 服务器颁发，作为您选择并适用于您的案例的 OIDC 授权类型的最后一步。
Upon reading, it seems Okta OpenID Connect can be one choice which issues a JWT. However I am not clear on how to use this. That is, when Okta issues a JWT should our UI or any client for that matter keep sending the JWT in the Authorization header to our APIs and then our APIs in turn should send the JWT to Okta to validate it?
认为此架构中有 3 个组件。依赖方(客户端)、身份服务器/授权服务器/OIDC 提供者和资源服务器(您的后端及其数据)。当授权服务器向依赖方发出 id_token 时，您的资源服务器也知道此 token 。因此，当您在资源服务器中请求数据时，您将向资源服务器出示您的 id_token，它知道它是否有效 id_token 或无效
Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints?
OIDC Provider(如果需要更复杂的操作，则为 Identity Server)，因为 OIDC 是授权(核心是 OAuth 2.0)和身份验证。
关于java - 使用 Okta 验证其余端点和 UI，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41663913/