Renew an Expiring SSO Client Secret
Renew or rotate the client secret your identity provider uses for SVIEW single sign-on before it expires, so nobody is locked out.
This guide shows you how to renew or rotate the client secret your identity provider uses for SVIEW single sign-on (SSO) before it expires, so that nobody in your organisation is locked out.
SVIEW has no passwords of its own. Your team signs in through your organisation's identity provider, such as Microsoft Entra ID, Google or GitLab. To trust SVIEW, that provider holds an app registration (an OAuth application) with a client secret, and CTO2B stores a copy of that secret in your SVIEW configuration. The two copies must match.
What happens when the secret expires
When the secret in your identity provider expires, nobody from your organisation can sign in to SVIEW. The identity provider refuses the login, and SVIEW shows an error after you pick your provider. With Microsoft Entra ID, the error usually mentions invalid_client or AADSTS7000222.
People who are already signed in may keep working until their session ends, which makes an expiry easy to miss until the next morning.
Microsoft Entra ID client secrets always have an expiry date, at most two years out. Google and GitLab OAuth application secrets do not expire by default, but you follow the same steps whenever you rotate one, for example after someone who could see it leaves.
If your organisation signs in through Okta, SVIEW connects to it over SAML, so there is no client secret. The item that expires is the Okta signing certificate. Follow the same overlap approach below, and send us the new certificate instead of a secret.
Prerequisites
- Administrator rights on the app registration (Entra ID) or OAuth application (Google, GitLab) that your organisation created for SVIEW
- The current secret's expiry date, so you can plan the change. In Entra ID this is under App registrations → your SVIEW app → Certificates & secrets.
Start at least two weeks before the expiry date. Creating a new secret does not cancel the old one, so the two can overlap while we switch over, and nobody loses access.
Steps
- In your identity provider, open the app registration or OAuth application used for SVIEW. Do not create a new application: the client ID, redirect URI and group settings stay as they are, and only the secret changes.
- Create a new client secret and give it an expiry date. In Entra ID, go to Certificates & secrets → Client secrets → New client secret.
- Copy the secret value straight away. Entra ID shows the value only once. The Secret ID next to it is not the secret, and SVIEW cannot use it.
- Leave the old secret in place for now.
- Raise a request in your dedicated Slack channel saying that your SSO client secret needs renewing, and include the new secret's expiry date. Do not paste the secret into the request, a ticket comment or a chat message. Say that you need to exchange a secret, and we will agree a secure way to pass it.
- Hand the secret over through the secure route we agree with you.
- We update your SVIEW configuration and tell you when the new secret is live.
Verify it worked
- Sign out of SVIEW, or open a private browser window.
- Sign in again through your identity provider. You land on the Dashboard for your Environments as usual.
- Ask one or two colleagues to sign in as well, ideally members of different groups, and check that each one still sees the Services they expect.
Once sign-in works with the new secret, delete the old secret in your identity provider. Until you delete it, it stays valid until its own expiry date.
Set a reminder
Put a calendar reminder about three weeks before the new secret's expiry date, and assign it to a team rather than to one person, so the reminder survives someone leaving. Do not rely on your identity provider to warn you in time.
Still having issues?
If sign-in fails after the change, or the old secret has already expired, raise a request in your dedicated Slack channel. Say which identity provider you use, when the problem started, and the error text shown after you pick your provider. Do not include the secret itself.
Related articles
- Set Up Your PushOps Access — how your team signs in to SVIEW
- User Profile — how your SSO identity appears in SVIEW
- Access Requests — short-lived access to databases and namespaces
Updated 26 days ago