SSO plugin choice
-
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
- 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?
- 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 anemail.The email is how you will "find" the correct local account.
When you save the shared cookie (with hostname
.example.com), save theidandemailin the jwt, and session sharing will use it to try and match a user. First run it won't find theid, but will match anemailand 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)
-
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)
-
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?
-
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?
-
thanks for clarifying, now I understnad fully how it sso works. However, I still don't understand how it works in case of sharing some token with session-sharing. If I this token ends, how can I refresh it using nodebb (In case, for instance, react app, I can create an axios interceptor which will go to required endpoint and if there is 401 it will go to the refresh endpoint and after to the required one) ? Or nodeBB is required just to see it once and it will be signed in until new one appearance or logout?
-
forgot to tag, sorry julian
-
forgot to tag, sorry julian
Rp1 if the session sharing token ends they would just log in again using the SSO handler. There is no refresh token support in the session sharing plugin at this time.
