使用我的自己的Web应用程序使用passwordjs管理单点登录-共享登录 [英] Managing single sign on using passportjs for my own web applications - sharing login

问题描述

如果我有5个不同的Web应用程序，它们都托管在不同服务器上各自的域中，我是否可以使用passport.js创建单一登录，将用户重定向到所有Web属性的登录位置?

If I have 5 different web applications, all hosted on their own domains on different servers, could I use passport.js to create a single sign-on where users are redirected to a place to login for all web properties?

我是否需要为此创建自己的自定义策略，或者有一种通用的可以用于这种场景的策略?

Would I have to create my own custom strategy for this or there is a generic one I can use for this type of scenerio?

推荐答案

无论您是只考虑登录还是要确保对Web，API和移动应用程序进行身份验证和授权，您都需要:OAUTH2

No matter if you are concern just for login or how ensure the authentication and authorization for your webs, apis and maybe your mobile apps, you will need : OAUTH2

为此，在最简单的情况下，您需要具有此端点或功能的oauth2提供程序或平台:

For that you need a oauth2 provider or platform with this endpoints or functionalities in the most easy scenario:

• https://secure.com/signin/oauth
  • 将URL返回到集中式登录名.响应几乎总是带有 302 重定向代码.
  • 示例:当您输入某些Google应用时，您会重定向到统一的集中式Google登录页面
  • https://secure.com/signin/oauth
    • Returns an url to the centralized login. Response almost always comes with 302 redirect code.
    • Example: When you enter to some google app, you are redirected to unified and centralized google login page
    • 代币生成.如果要满足oauth2规范，请使用access_token.
    • 令牌验证.您可以验证令牌的某些方面，例如:验证，到期时间等
    • 如果收到有效令牌，通常会返回基本用户信息(电子邮件).
    • 用户创建(名称，标识符，电子邮件，密码等)

    Passport.js依赖于oauth2提供程序，后者必须提供 spec 端点，例如google，facebook，auth0等.请查看完整列表: http://www.passportjs.org/packages/

    Passport.js relies on oauth2 providers which must offer a spec endpoints like google, facebook, auth0, etc. Review the complete list: http://www.passportjs.org/packages/

    因此Passport.js只会帮助您使用选定的oauth2提供程序来管理Web身份验证流程.

    So Passport.js just will help you to manage the web authentication flow with the selected oauth2 provider.

    大多数基本的oauth2流可以是:

    Most basic oauth2 flow could be:

    • 用户从其浏览器输入web.com
    • 部署在诸如nodejs + express之类的某些Web服务器(不是apache或nginx的基本服务器)中的web.com会检测到该新用户并仅为他打开会话
    • 此nodejs + express中的某些逻辑检测到用户尚未启动有效会话.通常这是存储在会话中的标志.另外，如果没有有效的会话，则表明用户尚未启动有效的会话
    • 如果用户的登录名无效，则您的nodejs逻辑会向oauth2平台询问登录网址，并得到类似以下内容的信息: https://secure.com的授权码交换(在回调步骤中接收)/oauth/token )和传统的用户电子邮件获取( https://secure.com/user/个人资料)，您可以说:我的用户已登录！
    • user enter to web.com from its browser
    • web.com deployed in some web server (not basic as apache or nginx) like nodejs+express detects this new user and open a session just for him
    • Some logic in this nodejs+express detect that user has not started a valid session. This is commonly a flag stored in session. Also if there is not a valid session, this indicates that user has not started a valid session
    • If user has not a valid login, your nodejs logic ask to the oauth2 platform for the login url and gets something like: https://secure.com/signin/oauth and returns this url with a 302 code
    • User browser(firefox, opera, chrome, etc) gets the web.com response as an url with 302 code and perform a redirect to that url.
    • User enter a valid credentials and is redirected to the origin app : web.com. This redirect is well known as : oauth2 callback or oauth2 redirect
    • Omitting the exchange of authorization code (received in callback step) for the access_token (https://secure.com/oauth/token) and the classic user email acquisition (https://secure.com/user/profile), you can say : My user is logged in!

    正如我所说，使用sso登录只是冰山一角.用户登录后，您将准备好使用有效的令牌(通常为jwt)以使用您的企业rest api.此时出现此问题:

    As I said you, login with sso is just the tip of the iceberg. After user login, you will have a valid token(commonly jwt) ready to use in order to consume your enterprise rest apis. At this point this question arise:

    • 具有邮件[e-mail]的简单用户可以使用api https://humanresources.com 并删除您组织的员工?
    • Can a simple user with mail [e-mail] consume an api https://humanresources.com and delete an employee of your organization?

    由于通常会向互联网开放api休息，因此具有有效令牌的任何人都可以尝试对您的api执行操作.同样在隔离网络(LAN)中工作的api中，该问题也是有效的.

    Since an api rest commonly is opened to the internet, anyone with a valid token could try to perform actions over your apis. Also in apis which work in a isolate networks (LAN), that question is valid.

    无论您使用的是API网关还是任何API内部的直接逻辑，在最简单的情况下，您都必须在OAUTH2 PLATFORM中使用以下功能:

    No matter if you are using an API Gateway or a direct logic inside any of your apis, you must need in the following features in your OAUTH2 PLATFORM in most easy scenario:

    • 注册您的所有应用:网络，api，移动等
    • 注册您的应用程序的选项
      • 对于Web应用程序，选项可以是/home，/form1，/admin等菜单选项
      • 对于rest api，选项是端点及其http方法.jane有权对 https://humanresources.com/employee 执行POST(创建)调用，但是jon，只需GET(全部阅读)
      • 对于移动应用程序，Web应用程序的选项相同:菜单
      • Register all of your apps: web, apis, mobile, etc
      • Register options for your apps
        • For web app, options could be the menu options like: /home, /form1, /admin, etc
        • For rest api, options are the endpoints and its http methods. jane have access to perform a POST(create) invocation to the https://humanresources.com/employee but jon, just GET (read all)
        • For mobile apps, options are the same for a web app: the menu

        | profile or role         | app                 | option         |
        |-------------------------|---------------------|----------------|
        | human-resources-admin   | human-resources-api | /employee POST |
        | human-resources-support | human-resources-api | /employee GET  |
        
        | user         | profile or role         |
        |--------------|-------------------------|
        | [e-mail] | human-resources-admin   |
        | [e-mail]  | human-resources-support |
        
        

        • 利用API网关的用户，个人资料，角色，应用和选项之间的先前关系，或者api内部的逻辑，您可以验证某些用户是否具有对api中的端点执行调用的必需访问权限./li>
          • With the previous relationship between user, profile, roles, apps and options your API GATEWAY or an logic inside of your apis you could validate if some user has or not has a required access to perform invocations to endpoints in your apis.

          网络流程为我们提供了有效的令牌.因此，如果您的网站需要使用一些api:

          The web flow give us a valid token. So if your web need to consume some api:

          • 用户 [e-mail] 已登录.
          • Web使用ajax对某些端点(例如 https://humanresources.com/employee )执行http调用POST方法
          • 网站必须将收到的令牌作为http标头发送到api端点.
          • 无论您是否具有API网关或api(库)中的逻辑，这都是确定 [e-mail] 是否有权访问 https://humanresources.com/employee POST
            • 从标题中提取令牌
            • 使用 https://secure.com/oauth/introspect-token 发送提取的令牌，调用的终结点(/employee)，http方法(POST)
            • 我们的 https://secure.com/oauth/introspect-token 端点 OAUTH2 PLATFORM (使用先前在用户，个人资料，角色，应用和选项之间创建的关系)必须能够检测[e-mail]是否有权执行POST操作通过 https://humanresources.com API.
            • 在使用API​​ GATEWAY的情况下，如果响应为true或某些标志指示允许用户执行http调用，则网关必须调用远程api.如果oauth2平台返回false，则不调用远程api，并且对ajax调用返回403(禁止)响应.Web必须能够向用户显示警告或错误消息
            • 如果未使用API​​ GATEWAY ，则使用api内部的内部逻辑(通常为http过滤器)代替，如果oauth2平台返回true，则过滤器必须传播调用直到后端api的控制器，以执行预期的逻辑.如果响应为假，则停止执行(未触摸控制器)并返回403错误.
            • User [e-mail] has logged in.
            • Web, using ajax perform an http invocation to some endpoint like https://humanresources.com/employee with POST method
            • Web must send the received token as a http header to the api endpoint.
            • No matter if you have a API GATEWAY or an logic inside of your api (library), this will be the flow to determine if [e-mail] has or not has access to https://humanresources.com/employee POST
              • extract the token from headers
              • consume https://secure.com/oauth/introspect-token sending the extracted token, invoked endpoint(/employee), http method (POST)
              • this https://secure.com/oauth/introspect-token endpoint of our OAUTH2 PLATFORM using the previous previous created relationship between user, profile, roles, apps and options must be able to detect if [e-mail] has access to perform a POST operation over https://humanresources.com api.
              • In case of API GATEWAY is being used, if response is true or some flag which indicates that user is allowed to perform the http invocation, the gateway must invoke the remote api. If oauth2 platform returns false, remote api is not invoked and a 403 (forbidden) response is returned to the ajax invocation. Web must be able to show a warning or error message to the user
              • In case of API GATEWAY is not used and instead of that, a internal logic inside api is used (commonly http filters), if oauth2 platform returns true, filter must propagate the invocation until the backend controller of the api in order to execute the expected logic. If response is false, stop the execution (controller was not touched) and return a 403 error.

              以下是一些选项及其说明:

              Here some options and its descriptions:

              • https://auth0.com
                • 身份很复杂.处理它.快速集成针对Web，移动和旧版应用程序的身份验证和授权，因此您可以专注于核心业务.
                • 用于现代应用程序和服务的开源身份和访问管理
                • Hydra是OAuth 2.0和OpenID Connect提供商.换句话说，是OAuth 2.0授权框架以及OpenID Connect Core 1.0框架的实现.这样，它将颁发OAuth 2.0访问，刷新和ID令牌，使第三方能够以用户的名义访问您的API.

                更多选项: https://oauth.net/code/

                开源

                • Glewlwyd
                • 钥匙斗篷
                • OAuth.io
                • ORY九头蛇
                • SimpleLogin

                • SSQ登录

                https://github.com/jrichardsz/oauth2-shield

                • 这是我创建oauth2平台的尝试.目前，只有非交互式用户可以生成令牌.我希望有更多的时间来添加说明的功能.

                商业

                • Auth0
                • Curity Identity Server
                • FusionAuth
                • Okta
                • 红帽单点登录
                • cidaas

                测试所选的oauth2提供程序是否满足您当前和将来的所有要求非常重要.

                It is very important to test if the selected oauth2 provider meets all of your current and future requirements.

                这篇关于使用我的自己的Web应用程序使用passwordjs管理单点登录-共享登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！