Rp1 couple things here...

If you want to enable SSO via your own IdP, use nodebb-plugin-sso-oauth2-multiple. That will allow you to configure a client without having to actually code... ideally.

If you want to have an auth cookie shared between subdomains, use nodebb-plugin-session-sharing.

Thanks for the answer, I have connected my own idp and it required just a little change in my code (adding displayName for /userinfo endpoint), the result was achieved much faster and better than with fusion auth solution.

I've read also about session-sharing, however, I am not sure that I've understand it fully. I'll be very grateful, if you could answer my questions

1. So, if I am sharing a cookie between my subdomains(for example: forum.example.com(nodebb app) and articles.example.com), it has a domain name of example.com, how forum.example.com will understand that this is exactly this user from the database? Does this user required to log in for first time, therefore, its id from my sso database is shared to nodebb database?
2. Also, if the cookie is taking a role of access token ( 15m lifespan ), can I share a refresh token to refresh it somehow?

Rp1 session sharing does not share any commonalities with SSO. Consider them separate items completely.

If you want them to work together, your best bet is to ensure that when your users register via your SSO IdP, that the user info endpoint provides both an id (that should be required anyhow), and an email.

The email is how you will "find" the correct local account.

When you save the shared cookie (with hostname .example.com), save the id and email in the jwt, and session sharing will use it to try and match a user. First run it won't find the id, but will match an email and store the id:uid reference for the next time.

The shared cookie can last as long as you want it to last, or as short as you want.

julian, Did I understand you correctly, that I can send cookie from my IdP and this cookie, if it has encoded inside email and id of the user from nodebb database, will be matched by session plugin, therefore the user will be signed in?

Also, could you please clarify, there is no mechanism to refresh this cookie? As I know it is considered a best practice to have access token (short life-span) and refresh token (long life-span)

Rp1 the SSO plugin does not save a cookie. A login (either via local username/password or via SSO) will generate a cookie, but this isn't the cookie used by session-sharing.

I go into more detail in the session-sharing readme: https://github.com/julianlam/nodebb-plugin-session-sharing/

julian, thanks, I've read it before. But my IdP(identity provider) can send cookies as response and this cookies can be shared through domain, therefore user will be signed in on my forum.

Also, could you please clarify, there is no mechanism to refresh this cookie? As I know it is considered a best practice to have access token (short life-span) and refresh token (long life-span)

Rp1 that's a use case I am unfamiliar with. Unfortunately at this time I don't think session sharing plugin is able to utilise that cookie.

It's an interesting idea though! It'd basically replace the need for the session sharing plugin!

julian, so there is no way to refresh token?

Rp1 a OAuth2 refresh token is used to trade in for a new short-lived access token (which I'm sure you knew already ), but there's no need for that for how NodeBB uses SSO. It calls the authorization endpoint a single time to log the user in, and essentially disposes of the access token after calling the user info endpoint.

Additional logins just restart the same login process. There's no need to maintain API access, which is why there's no need for a refresh token. Does that help?