Migrate from implicit flow to Authorization Code with PKCE

Starting with the Seismic release on December 14, 2026, new apps and new app versions in App Registry can't create new clients with implicit grant type. Use Authorization Code with PKCE (Proof Key for Code Exchange) instead. It is the current industry recommendation for browser-based apps.

📘

Do existing implicit apps need to change?

Not right away. Existing implicit apps keep working, and you can still update their redirect URLs. You must move to Authorization Code with PKCE when you need a new app version, for example to change the app's scopes.

What changes

The token is no longer exposed in the browser's address bar or history. That makes the code flow safer against token leakage and token injection.

Before you start

• Your app's domain and redirect URLs must still be registered with Seismic. You can reuse the same redirect pages.
• Upgrade to the latest oidc-client-ts. The sample in these docs uses oidc-client 1.6.1, which is no longer maintained and gets no security fixes. oidc-client-ts is its maintained successor, and it keeps the same UserManager API, so the change is small. It also supports only the code flow, with PKCE turned on by default, so upgrading moves you off the implicit flow at the same time. Install the latest release with npm install oidc-client-ts, or load a pinned version of its browser build.

Step 1. Create a new app version that uses Authorization Code

1. Sign in to the App Registration Portal at https://apps.seismic.com and open your app.
2. Create a new version of the app.
3. Under OAuth2 Information, set the grant type to authorization_code and configure it like this:
   • Require PKCE: checked.
   • Require client secret: off. Without a client secret, the app is a public client and relies on PKCE only, which is what a browser app needs.
   • Client secret: leave it empty. Don't click Generate.
4. Keep the same redirect URIs, for example https://YOUR_UI_SERVER/auth_callback, and the same scopes, unless you need to change them.
5. Save the version and note its client ID. A new version gets a new client ID [CONFIRM], so you'll use it in step 2.

Step 2. Update your client page

In client.html, change response_type to code, and set client_id to the client ID of the new version. Nothing else needs to change:

var settings = {
    authority: 'https://auth.seismic.com/tenants/<tenant name here>',
    client_id: '<client_id of the new app version>',
    redirect_uri: '<your redirect url>',
    silent_redirect_uri: '<redirect url for silent flows>',
    scope: 'seismic.reporting',
    response_type: 'code',   // was: 'token'
    loadUserInfo: false
};
var manager = new Oidc.UserManager(settings);

With response_type: 'code', the library does the PKCE work for you:

• It creates a random code_verifier and sends its SHA-256 hash as code_challenge (with code_challenge_method=S256) to https://auth.seismic.com/tenants/{tenant}/connect/authorize.
• When Seismic redirects back with ?code=..., it exchanges the code at https://auth.seismic.com/tenants/{tenant}/connect/token, sending grant_type=authorization_code, the code, the redirect_uri, the client_id and the code_verifier.

signinPopup(), signinRedirect() and signinSilent() all work the same way as before. So does the authentication_mode: 'directlogon' extra query parameter.

Step 3. Keep your redirect page

popup.html doesn't need any change. signinPopupCallback() (and signinSilentCallback() or signinRedirectCallback()) read the authorization code from the query string and complete the token exchange.

One difference: with the code flow, the response comes back in the query string (?code=...&state=...) rather than the URL fragment (#access_token=...). If any of your own code reads the token straight from window.location.hash, remove it and use manager.getUser() or the addUserLoaded event instead, as the sample client page does.

Step 4. Install and test

1. Install the new app version in each tenant where you use the app.
2. Open your client page (for example client.html?TENANT_NAME), sign in, and confirm that the Authorization: Bearer ... value appears and that API calls succeed.
3. Test silent sign-in if you use it.
4. When everything works, retire the old implicit version.

If you call the endpoints yourself (without oidc-client)

Follow the existing PKCE guide, starting with Get the user's authorization code. Use the client ID of the new app version, and leave the client secret out of the token request.

FAQ

Will my existing implicit app stop working on December 14, 2026? No. Existing implicit apps keep working.

Can I still change the redirect URLs of my implicit app? Yes.

Can I change the scopes of my implicit app? No. A scope change creates a new app version with a new client, and new implicit clients can't be created. Move the app to Authorization Code with PKCE as part of the scope change.

Do I need a client secret on the PKCE replacement client? No. Browser apps use PKCE instead of a secret. Never put a client secret in browser code.

There is one exception. If the token exchange runs on your own backend server rather than in the browser, the app is a confidential client. It can then use PKCE together with a client secret: turn on Require client secret, and keep the secret on the server only. When you migrate a browser-only implicit app, leave Require client secret off.

Does the access token lifetime change? Not because of this migration. Plan for tokens that expire after a few hours, as today, and use silent sign-in to renew them.

Can I change the client secret on my existing implicit client? Nice try, but there's nothing to change. Implicit clients never had a secret, because they run in the browser, where a secret can't be kept safe. That's also why their replacement, Authorization Code with PKCE, doesn't need one either.