Welcome to WuJiGu Developer Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
761 views
in Technique[技术] by (71.8m points)

node.js - Managing single sign on using passportjs for my own web applications - sharing login

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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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 platform functionalities

Almost all the most used and modern security providers, at least has these endpoints or functionalities:

Passport.js

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

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

Oauth2 web flow

Most basic oauth2 flow could be:

  • 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!

Secure Rest Apis

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:

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.

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:

  • 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
  • Create profiles and/or roles to have a matrix :
| 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         |
|--------------|-------------------------|
| [email protected] | human-resources-admin   |
| [email protected]  | human-resources-support |

  • 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.

Oauth2 Api flow

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

  • User [email protected] 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 a logic inside of your api (library), this will be the flow to determine if [email protected] 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 [email protected] 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.

IAM

Modern security platform offer a lot of features, one of them is the oauth2 protocol (spec endpoints). These platform are known as Identity and Access Management (IAM). Let's check some of their descriptions:

  • https://auth0.com
    • Identity is Complex. Deal with it. Rapidly integrate authentication and authorization for web, mobile, and legacy applications so you can focus on your core business.
  • https://www.keycloak.org/
    • Open Source Identity and Access Management for Modern Applications and Services
  • https://www.ory.sh/hydra/docs/index
    • Hydra is an OAuth 2.0 and OpenID Connect Provider. In other words, an implementation of the OAuth 2.0 Authorization Framework as well as the OpenID Connect Core 1.0 framework. As such, it issues OAuth 2.0 Access, Refresh, and ID Tokens that enable third-parties to access your APIs in the name of your users.

Here more options: https://oauth.net/code/

Open Source

Commercial


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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to WuJiGu Developer Q&A Community for programmer and developer-Open, Learning and Share
...