Configure the Secure Access Monitor plugin
The Secure Access Monitor (SAM) plugin is a managed Chrome extension. Configure the SAM plugin to monitor for unmanaged OAuth grants and securely transfer the collected data to Okta Identity Security Posture Management (ISPM).
Before you begin
-
Your Okta org is connected to Google Chrome Enterprise. The SAM plugin only works on managed Chrome browsers. See Integrate Okta with Chrome Enterprise.
-
Your Chrome browsers are enrolled into Google Chrome Enterprise Core. If they aren't, follow the steps in Enroll cloud-managed Chrome browsers. This is required to provision the Google CA certificate. Third-party MDM solutions alone are insufficient. Windows devices require additional registry settings or MDM policy to complete the enrollment.
-
You have the super admin role.
-
You have access to the Google Admin Console.
-
You have an active Okta ISPM tenant (ISPM or Okta AI License).
-
Your security policies don't block OAuth grants.
-
You're aware that the SAM plugin client certificate interferes with manual certificate selection flows (Smart Card, PIV, Legacy Device Trust).
-
If you use a SASE solution, you've configured it to exempt the Okta URL (https://<org>.mtls.okta.com) from TLS inspection.
-
Your browser policies don't pin the browser to a specific client certificate. This prevents users from authenticating through Device Trust.
Configure the Chrome browser
Configure the certificate to be sent automatically to the Okta data endpoint. First, provision and download the Google Certificate Authority. Then, configure the client certificate settings.
Provision and download the Google Certificate Authority
Provision and download the Google Certificate Authority. For more information, see Configure Chrome browser to provision its own client certificate (Step 1: Provision a Google CA).
-
Sign in to the Google Admin Console with an admin account.
-
In the Google Admin Console, go to .
-
Select the organizational unit that you want to apply the Google Certificate Authority configuration to.
-
On the Connectors page, click + New provider configuration.
If you already have a provider configuration set up, like for Okta Device Trust, create the Google CA as an additional provider configuration. Both can be applied to the same organizational unit.
-
In the Set up a provider panel, find Google Certificate Authority and click Set up.
-
Click Provision.
-
On the Connectors page, click Details for Google Certificate Authority.
-
Download GoogleCertificateAuthority.pem.
Configure the client certificate setting
Configure the client certificates setting. For more information, see Configure Chrome browser to provision its own client certificate (Step 2: Configure the Client certificates setting).
-
Sign in to the Google Admin Console with an admin account.
-
In the Google Admin Console, go to .
-
Select the appropriate organizational unit.
-
On the User & browser settings tab, search for and click Client certificates.
-
In the Automatically select for these sites field, enter the following and replace <org> with your Okta org subdomain: {"pattern": "https://<org>.mtls.okta.com", "filter": {"ISSUER": {"CN":"Chrome Enterprise CA"}}}.
If your org is a preview org, replace <org>.mtls.okta.com with <org>.mtls.oktapreview.com.
-
To verify that the policy was applied, use a managed Chrome browser and go to chrome://policy/. Locate AutoSelectCertificateForUrls in the policy list and confirm your entry appears there.
Upload the Certificate Authority to the Okta Admin Console
Upload the CA that you got from the Google Admin Console into the Okta Admin Console. This certificate is required for the client certificate authentication process.
-
In the Okta Admin Console, go to Security > Device Integrations.
-
Click the Certificate authority tab.
-
Click Add certificate authority.
-
For Issue certificate to, select Secure Access Monitor plugin.
-
Upload the CA certificate chain. The file type must be .pem.
Install the plugin
-
Sign in to the Google Admin Console.
-
Go to Chrome browser > Apps & extensions.
-
Click the Users & browsers tab.
-
Select your Okta organizational unit.
If you want to test the installation on a subset of users, create a group or organizational unit of select users and choose that instead. For more information, see Groups and Add an organizational unit.
-
Click the + icon on the bottom right and select Add Chrome app or extension by ID.
-
In the Extension ID field, enter the SAM plugin ID: galipinbbdandeicdicjbalcbpdbljjj.
-
Click Save. The extension is now displayed in your apps and extensions.
-
Click the Secure Access Monitor extension to open the settings panel.
-
Change Allow install to Force install.
-
In the Policy for extensions field, enter the following JSON and replace <org> with your Okta org subdomain:
{ "orgUrl": { "Value": "https://<org>.okta.com" } }. -
Click SAVE.
For more information, see Automatically install apps and extensions.
Sign in users to managed Chrome profiles
For the configuration to take effect, your end users need to sign in to their managed Chrome profiles and their Okta End-User Dashboard using your Okta org URL.
Verify the installation
To verify that the SAM plugin is correctly installed and is capturing OAuth events, use the Chrome Developer Tools.
Check the extension storage
-
In your managed Chrome browser, go to chrome://extensions.
-
Toggle on Developer mode.
-
Locate the Secure Access Monitor extension and click service worker.
-
In the DevTools window, click the Application tab.
-
From the navigation menu, select .
-
Check the fields in the following table.
| Field | Description | Expected value |
|---|---|---|
|
userInfo |
The identity anchor for the plugin. Contains the |
Populated with a valid |
|
pendingOauthEvents |
The local queue of captured OAuth grant attempts. |
Populated after a user initiates an OAuth grant flow. Cleared after the plugin successfully transmits events to Okta (HTTP 202 Accepted). |
|
orgUrl |
The Okta tenant URL configured in Google Admin. |
Matches |
SAM OAuth event lifecycle
The SAM plugin uses a collect-store-flush data collection model. When a user initiates an OAuth flow, the SAM plugin intercepts the request and stores it locally in pendingOauthEvents. The data remains in this pending state until a batch send is triggered.
A batch-send is triggered when one of the following conditions is met:
-
100 events have been collected in local storage.
-
A 24-hour cycle completes with events older than 24 hours.
Verify registration and event transmission
JSON Web Key Set (JWKS) and token calls aren't triggered immediately after installation. These authentication flows are initiated only during a batch-send event.
After a batch-send occurs, confirm that registration and transmission were successful.
-
In the DevTools window, click the Application tab.
-
In the navigation menu, select Storage > Extension Storage > Local.
-
Check the storage keys in the following table.
| Storage key | Expected value | Description |
|---|---|---|
|
jwkRegisterResp |
Object present |
JWKS registration with Okta was successful. |
|
authStatus |
|
A valid access token was obtained from the backend. |
|
accessToken |
Token string present |
The plugin is fully authenticated and ready to transmit. |
|
pendingOauthEvents |
|
All locally queued events have been flushed to Okta. |
You can also confirm the batch-send in the Network tab of the DevTools window. A successful batch-send produces the following call sequence:
-
POST /jwks: The plugin registers its public key. -
POST /token: The plugin exchanges its registration for an access token. -
POST /events: The plugin transmits the telemetry payload (returns HTTP 202 Accepted).
Check the ISPM dashboard
Once you've configured and deployed the SAM plugin, data flows from the end user's browser to Okta.
To verify the configuration, check that data is flowing to Okta by reviewing the Okta ISPM dashboard. It may take up to two days for the data to appear in the ISPM console. See Discover shadow AI agents using the SAM plugin.
