我们有一个使用SprintBoot和嵌入式Jetty服务器的Java 8后端应用程序。
应用程序的UI是使用React构建的单页面应用程序。
目前,我已通过使用spring security SAML扩展与Okta集成来启用身份验证。当Okta将断言发布到我的应用程序时,我创建了一个会话,并在cookie中发送了JSESSIONID。
直到现在,当我们有一个非常简单的UI提供少量UI组件时,这很好。
但是,现在我们的后端有几个REST端点,我们也希望它们也经过身份验证。 REST端点本身是使用Jersey开发的。
如果我理解正确,SAML显然不是纯REST基于端点的选择,因为SAML主要是基于浏览器的协议。这些REST端点将由我们的UI调用,我们希望它们通过Postman独立调用或用于测试。
当客户端调用这些REST API时,我猜客户端应该发送一个Authorization标头,该标头应该由后端的一个验证过滤器检查。在验证客户端和用户之后,过滤器应该在SecurityContext中注入用户信息,因为Jersey在所有REST端点中注入SecurityContext。然后,从此SecurityContext中获取用户变得更加容易。
阅读后,似乎Okta OpenID Connect可以成为发行JWT的唯一选择。但是我不知道如何使用它。也就是说,当Okta发布JWT时,我们的用户界面或任何客户端是否继续将AuthorWat文件中的JWT发送到我们的API,然后我们的API又将JWT发送给Okta验证它?
问题是提供UI和会话登录以及验证REST端点的最佳选择是什么?更不用说REST API本质上是无状态的。
答案 0 :(得分:1)
当客户端调用这些REST API时,我猜客户端 应发送一个应由其中一个检查的Authorization标头 后端的身份验证过滤器
在OpendID Connect(OIDC)中,Authorization标头中的值为 id_token ,可以采用JWT格式。这个 id_token 由OIDC服务器发布,作为您选择并适用于您的案例的OIDC 授权类型的最后一步。
在阅读时,似乎Okta OpenID Connect可以是一个选择 发布JWT。但是我不知道如何使用它。那就是 如果我们的UI或任何客户端保持这个问题,Okta会发布JWT 将授权标题中的JWT发送到我们的API然后我们的 API反过来应该将JWT发送给Okta进行验证吗?
认为此架构中有3个组件。依赖方(客户端),身份服务器/授权服务器/ OIDC提供商和资源服务器(您的后端及其数据)。当授权服务器向依赖方发出 id_token 时,您的资源服务器也会知道此令牌。因此,当您在资源服务器中请求数据时,您将id_token呈现给资源服务器,并且它知道它是否有效 id_token
问题是什么是两者的最佳选择,即UI的登录 以及会话和身份验证REST端点?
OIDC Provider(如果您需要更复杂的操作,则为Identity Server),因为OIDC是授权(核心的OAuth 2.0)和身份验证。