使用Okta对其余端点和UI进行身份验证 [英] Authenticating rest endpoints and the UI using Okta

问题描述

我们有一个使用SprintBoot和嵌入式Jetty服务器的Java 8后端应用程序.

We have a Java 8 backend application using SprintBoot with an embedded Jetty server.

应用程序的UI是使用React构建的单页应用程序.

The UI for the application is a Single Page Application built using React.

当前，我已通过使用Spring Security SAML扩展与Okta集成来启用身份验证.当断言由Okta发布到我的应用程序时，我创建一个会话并将JSESSIONID发送到cookie中.

Currently I have enabled authentication by integrating with Okta using the spring security SAML extension. When the assertion is posted by Okta to my app, I create a session and the JSESSIONID is sent in the cookie.

到现在为止，当我们有一个非常简单的UI服务几个UI组件时，这还不错.

This was fine until now when we had a very simple UI serving few UI components.

但是，现在我们的后端中有几个REST端点，我们也希望它们也通过身份验证. REST端点本身是使用Jersey开发的.

However, now we have several REST endpoints in our backend and we would want them to be authenticated as well. REST endpoints themselves are developed using Jersey.

如果我理解正确，那么SAML显然不是纯基于REST的端点的选择，因为SAML主要是基于浏览器的协议.这些REST端点也将由我们的UI调用，我们希望通过Postman或进行测试的方式独立调用它们.

If I understand correctly, SAML is clearly not the choice for pure REST based endpoints as SAML is mainly a browser based protocol. These REST endpoints will be called by our UI as well we want them to be independently called via Postman or something for testing.

当客户端调用这些REST API时，我猜想客户端应该发送一个Authorization标头，该标头应由后端中的身份验证过滤器之一进行检查.在验证客户端和用户之后，过滤器应在SecurityContext中注入用户信息，因为Jersey在所有REST端点中注入了SecurityContext.然后，从此SecurityContext获取用户变得更加容易.

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. After validating the client and the user, the filter should inject the user information in the SecurityContext because Jersey injects SecurityContext in all of the REST endpoints. Then it becomes easier to fetch the user from this SecurityContext.

阅读时，似乎Okta OpenID Connect可以成为发布JWT的一种选择.但是我不清楚如何使用它.也就是说，当Okta发出JWT时，我们的UI或任何与此相关的客户端是否应继续将Authorization标头中的JWT发送给我们的API，然后我们的API依次将JWT发送给Okta进行验证?

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?

问题是同时为UI和会话以及身份验证REST端点提供服务的最佳选择是什么?更不用说REST API本质上将是无状态的.

Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints? Not to mention the REST APIs will be stateless in nature.

推荐答案

当客户端调用这些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)中，授权标头中的值是 id_token ，该值可以为JWT格式.此 id_token 由OIDC服务器发出，是您选择的OIDC 赠款类型(适用于您的案件)的最后一步.

In OpendID Connect (OIDC), that value in the Authorization header is id_token which can be in JWT format. This id_token is issued by the OIDC server as the last step for whichever OIDC grant type you choose and applicable to your case.

阅读时，似乎Okta OpenID Connect可能是一种选择 发布JWT.但是我不清楚如何使用它.也就是说，当 Okta发出JWT，如果我们的UI或与此相关的任何客户端保持该状态 将Authorization标头中的JWT发送到我们的API，然后发送给我们 反过来，API应该将JWT发送给Okta进行验证吗?

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个组件.依赖方(客户端)，Identity Server/授权服务器/OIDC提供程序和资源服务器(您的后端及其数据).当授权服务器发出并且 id_token 给依赖方时，您的资源服务器也知道此令牌.因此，当您在资源服务器中请求数据时，会将ID_token呈现给资源服务器，它会知道它是否有效 id_token

Think that you have 3 components in this architecture. Relying Party (client), Identity Server / Authorization Server / OIDC Provider and Resource Server (your backend and it's data). When Authorization Server issues and id_token to Relying Party, your Resource Server also knows this token. So when you request for data in resource server, you will present your id_token to Resource Server and it knows if it is valid id_token or not

问题是同时为用户和用户界面提供服务的最佳选择是什么 和一个会话并验证REST端点?

Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints?

OIDC提供程序(如果需要更复杂的操作，则为Identity Server)，因为OIDC是授权(核心为OAuth 2.0)和身份验证.

OIDC Provider (or Identity Server if you need more complex operation), since OIDC is Authorization (OAuth 2.0 at core) and Authentication.

这篇关于使用Okta对其余端点和UI进行身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！