> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/authentication/passwordless-for-web-apps/use-cases/entra-passkey-for-frontline-workers/browser-authentication-via-chrome-extension.md).

# Browser Authentication via Chrome Extension

***

For desk-based workers, the 1Kosmos Chrome extension brings the same passkey + LiveID authentication experience to the browser. The extension integrates with the Entra login page — when a user clicks **Log in with Security Key**, the extension handles the authentication silently after a one-time activation.

The extension is distributed to users via the **Chrome Web Store**.

#### Prerequisites

In addition to the common prerequisites above:

* AdminX access to create an OIDC application
* Chrome browser on the user's machine
* Extension available on the Chrome Web Store

#### Create an OIDC Application in AdminX

The extension activation flow requires a dedicated OIDC application in AdminX. This application issues the client ID that the extension uses to initiate the activation request.

1. In AdminX, navigate to **Applications** and click **Create Application**
2. Set **Grant Type** to `Authorization Code` and **Application Type** to `Native`
3. Set the **Sign-in Redirect URI** to `http://127.0.0.1/callback` - the extension listens on this URL to complete the activation redirect
4. Under **Scopes**, enable the following:

| Scope                | Purpose                                   |
| -------------------- | ----------------------------------------- |
| `profile`            | User profile access                       |
| `openid`             | OIDC authentication                       |
| `extension:activate` | Required for browser extension activation |

5. Click **Create** and copy the **Client ID** - this goes into the extension config JSON

#### Configure the Extension Config JSON

The extension config is a JSON file that links the extension to your 1Kosmos community and authentication workflow. Prepare the file with the following values:

json

```json
{
  "tenant_dns": "<your-tenant-dns>",
  "community_name": "<your-community-name>",
  "access_code": "<authentication-workflow-access-code>",
  "oidc_client_id": "<client-id-from-oidc-application>"
}
```

This config file is bundled with the extension for Chrome Web Store distribution. If a config update is needed post-deployment, users can download and apply a new config from the extension settings page.

#### Self-Enrollment (Register Entra Passkey)

The browser extension (Chrome and Edge) now lets frontline workers self-enroll their Entra passkey directly, without an admin creating and sharing a workflow link. Previously, a community admin had to log into AdminX, create a registration workflow instance, and share the link with the user, which added friction for large-scale frontline deployments.

Registration now starts from the extension itself. The registration workflow still performs identity verification (IDV), LiveID authentication, and Entra passkey registration — the same flow as before. Only the trigger changes.

**How Registration Starts**

The extension supports two ways to start registration:

* **User-initiated** — The user clicks the **Register Entra Passkey** button in the extension. The extension creates a new registration workflow session and opens it in a new browser tab.
* **Auth-failure-initiated** — When the user selects the passkey login option on `login.microsoft.com` and the authentication workflow returns "No Credential Found" (no passkey registered), the extension automatically opens a new registration workflow session in a new tab.

In both cases, the user completes IDV, LiveID authentication, and Entra passkey registration, then returns to the login flow.

**Configuration**

The extension configuration must include a `registrationAccessCode` for the registration workflow, in addition to the existing fields:

```json
{
  "tenantDns": "",
  "communityName": "",
  "authAccessCode": "",
  "oidcClientId": "",
  "registrationAccessCode": ""
}
```

**Prerequisites**

* The browser extension is already configured and activated (Chrome or Edge).
* `registrationAccessCode` is set in the extension configuration, pointing to the passkey registration workflow.

**Impact**

* **Who is affected:** Frontline workers using Entra passkey authentication via the browser extension.
* **Breaking changes:** None. Existing authentication workflows are unchanged. The registration capability is additive and requires setting the new config key.

#### Extension Activation (First-Time Login)

When a user logs in for the first time after installing the extension, they complete a one-time activation tied to their identity. This ensures the extension is bound to the correct user before it can authenticate.

1. User navigates to the Entra login page and clicks **Sign In**
2. User clicks **Log in with Security Key** — the 1Kosmos extension activation pop-up appears
3. User clicks **Activate with 1Kosmos** and is redirected to AdminX for one-time activation
4. User authenticates via LiveID biometric
5. Extension is activated — user is redirected back to the login flow and logged into Entra

After activation, the extension status shows as **Configured and Activated** in the extension settings page.

#### Authentication Flow

For all subsequent logins, the extension handles authentication automatically without any additional setup from the user.

1. User navigates to the Entra login page and clicks **Sign In**
2. User clicks **Log in with Security Key** — the extension detects it is already activated and redirects automatically to the authentication workflow
3. User completes LiveID biometric verification (selfie)
4. The passkey challenge is signed and the user is logged into Microsoft Entra

***

### Troubleshooting

#### Intune Configuration Not Applied to Device

If the app configuration is not reflecting on the device, follow these steps in order:

1. **Force sync** — On the device, open Company Portal → Devices → Sync. From Intune Admin Center, go to Devices → select device → Sync. Wait up to 15 minutes.
2. **Check group assignment** — Confirm the user/device is in the group assigned to both the app and the config policy
3. **Check device compliance** — A non-compliant device may be blocked from receiving configs. Resolve compliance issues before retrying.
4. **Reinstall the app** — Delete the app on the device, reinstall via Company Portal, and sync again
5. **Verify MDM profile** — Go to Settings → General → VPN & Device Management and confirm the Intune profile is installed and trusted. Re-enroll if missing.
6. **Review Intune logs** — In Intune Admin Center, go to Troubleshooting + support → select the user → check App install status and Configuration policy status

#### Extension Not Activating

* Confirm the OIDC application has all three scopes enabled: `profile`, `openid`, `extension:activate`
* Verify the redirect URI in the OIDC application is exactly `http://127.0.0.1/callback`
* Confirm the `oidc_client_id` in the extension config matches the Client ID of the OIDC application in AdminX
* Check that the authentication workflow is active and the access code in the config is correct

***

### Known Limitations

* Workflow UI import and Swagger cannot be used to inject workflow JSONs in Production — manual database injection is required
* A "Credentials not bound" error may appear during authentication if multiple LiveIDs are enrolled across users in the same community. This does not block authentication and is under review.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.1kosmos.com/authentication/passwordless-for-web-apps/use-cases/entra-passkey-for-frontline-workers/browser-authentication-via-chrome-extension.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.