Domain, access and SEO

Frequently asked questions

• Can I have more than one SSO configuration on a help center?

  No. Each help center has one JWT configuration: one Login URL and one shared secret, plus an optional Issuer and Audience.

  Several of your own apps can still sign readers in to the same help center, as long as they all sign with that shared secret and match the Issuer and Audience if you set them. Readers who open the help center directly always go to the one Login URL, so that endpoint has to handle all of them.

  If two audiences sign in through different systems, such as customers and partners, give each its own help center with its own SSO setup. Each help center needs a plan that includes SSO. See Create another help center.

  How JWT single sign-on works on the developer portal shows how the pieces fit together.

  Related articles

  • Sign readers in with your own login (JWT SSO)

  • Create another help center

  Read more →

• Can different readers get different access?

  Not through SSO. Everyone who signs in with SSO gets the same reader access, and a role claim in the token is ignored.

  SSO readers see everything that's open to all readers of your help center. Categories shared with team members only, and categories or articles shared with selected team members, stay hidden from them. So you can keep internal content out of reach, but you can't show one group of SSO readers something the others can't see: private categories are shared with team members, not with SSO readers. See Make a category private.

  If groups of readers need different content, give each group its own help center with its own SSO setup. See Create another help center. SSO never gives access to the dashboard: to add a colleague to your team, invite them under Users.

  What SSO does and doesn't do is in How JWT single sign-on works on the developer portal.

  Related articles

  • Sign readers in with your own login (JWT SSO)

  • Make a category private

  • Roles and permissions

  Read more →

• What if a reader's email changes on our side?

  Send an external_id claim in every token, from the first sign-in, and the reader keeps the same account in your help center when their email changes.

  HelpCenter.io recognizes an SSO reader by their email address or by their external_id. Use your own stable user ID, the one that never changes, as the external_id. When a token arrives with a new email but a known external_id, HelpCenter.io signs in the reader it already knows.

  {
    "jti": "the key HelpCenter.io sent",
    "iat": 1767225600,
    "exp": 1767225900,
    "email": "new.address@example.com",
    "name": "Jane Doe",
    "external_id": "4815"
  }

  • Add it from the start. A reader created without an external_id stays matched by email only, even if later tokens include one. A changed email then creates a new reader.

  • Details stay as they were. HelpCenter.io keeps the email, name and other details a reader was created with, so their comments keep showing the name from their first sign-in.

  See JWT claims and validation rules on the developer portal.

  Related articles

  • Sign readers in with your own login (JWT SSO)

  Read more →

• How long should my SSO tokens live?

  Short: 300 seconds (5 minutes) is a good default, and it's what the Token TTL setting recommends.

  A token only has to live long enough to reach HelpCenter.io. Your Login URL redirects the reader straight to /sso/jwt, so a few minutes leaves plenty of room, and once the reader is signed in the token isn't needed again.

  • Sign-in keys work once. The key HelpCenter.io sends to your Login URL is good for one sign-in, so a longer token life gives readers nothing extra. It only widens the window in which a leaked token could be used.

  • Token TTL caps widget tokens only. The widget rejects tokens older than your Token TTL (30 to 86,400 seconds), even if their exp is later. For sign-in through your Login URL or an iframe, exp is the only limit, so keep it short on your side.

  • The widget gets fresh tokens on its own. It asks your onAuthExpired function for a new one when it needs it, so short tokens don't bother your readers.

  • Clocks matter. exp is required, and HelpCenter.io allows 30 seconds of difference on iat and exp. Keep your server's clock in sync, for example with NTP.

  The full rules are in JWT claims and validation rules on the developer portal.

  Related articles

  • Sign readers in with your own login (JWT SSO)

  • Sign readers into the widget with a JWT on the developer portal

  Read more →

• Can I rotate the SSO shared secret without downtime?

  Not completely. A help center has one shared secret at a time, so the moment you save a new one, tokens signed with the old secret stop working.

  You can keep the gap to a few moments:

  1. Pick a quiet time for your readers.

  2. Prepare the new secret. Either click Regenerate in Settings → Single sign-on, confirm the warning and copy the value, or create your own of at least 64 characters. The new secret doesn't take effect until you save.

  3. Put the new secret in your server's configuration, ready to deploy.

  4. Click Save JWT settings and deploy the new secret at the same time.

  Readers who are already signed in to the help center stay signed in. Sign-ins and widget requests during the gap fail, and work again as soon as your server signs with the new secret. A reader caught in the middle only needs to try again. See Troubleshoot single sign-on on the developer portal.

  Related articles

  • Sign readers in with your own login (JWT SSO)

  Read more →