A plain definition, a simple picture, and the sentence worth remembering.

Okta is an identity platform. It keeps the official list of who your people are and decides which applications each person may open. Most modern applications cooperate with Okta through standard protocols. They trust Okta’s word about who a user is, so the user never gives the application a password. This approach is called federation.

Some applications cannot do federation. They only have a sign-in page that expects a username and a password. For these, Okta offers Secure Web Authentication. In SWA, Okta stores the username and password for the application, protected by encryption. When the user clicks the application’s tile in their Okta dashboard, a browser extension called the Okta Browser Plugin opens the application’s sign-in page, fills in the stored username and password, and submits the form. The user lands inside the application as if they had typed everything themselves.

The word “secure” in the name means that the credentials are stored encrypted and delivered only to an authenticated user on a protected channel, so the user does not have to remember or type them. It does not mean that SWA is as strong as federation. The application still checks a password. That difference matters, and we return to it often.

To feel why SWA exists, look at the long tail of applications every organization owns.

Every company accumulates applications over the years, and they do not all arrive with the latest security features. Some were written before modern sign-in standards existed. Some are small tools built by tiny vendors who never invested in federation. Some belong to governments, banks, or industry bodies and are used by many organizations on the vendor’s own terms. Some are simply shared accounts on public websites. The result is a long tail of applications that only understand the username and password form.

What life looks like without SWA

When these applications sit outside single sign-on, several problems appear together.

Password sprawl. Each application has its own password. People reuse the same one across applications, write them on notes, or store them in unmanaged spreadsheets. When one application is breached, reused passwords spread the damage.

Slow, risky onboarding and offboarding. A new employee must be given each credential by hand. When someone leaves, administrators must remember every application that person could open. Forgotten accounts linger for months.

No central visibility. The security team cannot see who uses which application or when, because those sign-ins never touch the central identity system.

Shared accounts with shared secrets. Teams that share one login, such as marketing with social media pages, pass the password around in chat messages. Nobody can tell who did what, and removing a person means changing the password for everyone.

SWA sits at a meeting point between two long histories: password managers and single sign-on standards.

Why it still matters

It is tempting to treat SWA as a relic. In reality, many organizations still depend on it. Mergers bring in legacy tools. Industry portals and public websites rarely change. Shared accounts remain common. And not every business can wait for vendors to catch up. Okta therefore keeps SWA available and maintains a large catalog of pre-built SWA integrations in the Okta Integration Network. Knowing how to use SWA well, and when to leave it behind, is a practical skill for any Okta administrator.

Ten terms carry the whole topic. Each is explained with what it is, why it exists, and where you will meet it.

The central trade

Almost every SWA discussion comes back to one trade. SWA gives you central control over who may launch the application, and convenience for users. It does not give you central control over how the application itself authenticates, because the application still uses its own password check. Keep that trade in mind, and many design decisions become obvious.

When you can choose, which method should you use? The answer is almost always federation. Here is why.

Okta supports several ways for a user to sign in to an application. SAML and OpenID Connect are federation protocols. The application trusts a signed message from Okta that says who the user is. SWA is different. Okta never tells the application anything about the user. Instead, it fills in a password form. The application sees what looks like an ordinary person typing a password.

A simple decision rule

The small extension that does the typing, and the reason SWA works at all.

A web page is controlled by the browser, and ordinary websites are not allowed to reach into other websites and type in their forms. That is a vital safety rule of the web. To fill a username and password into someone else’s sign-in page, a program needs special permission from the browser. A browser extension can hold that permission, and the Okta Browser Plugin is such an extension.

What the plugin does

How users get it

The plugin is available for the major desktop browsers, usually through each browser’s extension store. Individual users can install it themselves, which is simple but unreliable across a large organization. Administrators usually deploy it centrally using the tools that manage browsers and devices, such as group policy or a mobile device management platform. A managed installation means every user has the plugin without any action, and users cannot remove it by accident. Which browsers are supported and how updates work can change, so confirm in current Okta documentation.

What it is not

The plugin is not needed for federated applications that use SAML or OpenID Connect, because those applications trust Okta directly. It is mainly for SWA. It is also not a general-purpose personal password manager, even though it behaves a little like one. It fills the credentials that Okta holds for assigned applications and does not hold everything a person types into the web.

A map of every actor involved when someone launches an SWA application.

flowchart LR
  USER["User"] --> DASH["Okta Dashboard"]
  DASH --> PLUGIN["Okta Browser Plugin"]
  PLUGIN |"HTTPS"| OKTA["Okta Org"]
  OKTA --> VAULT["Encrypted Credential Store"]
  OKTA --> POL["Sign-On and Authentication Policies"]
  PLUGIN --> APPPAGE["Application Sign-In Page"]
  APPPAGE --> APP["Web Application with its own password check"]
  OKTA --> LOG["System Log"]
    

Walking through the boxes

User. The person who wants to open the application. They authenticate to Okta first, perhaps with a second factor.

Okta dashboard. The page that shows the user’s assigned application tiles. Clicking a tile starts the launch.

Okta Browser Plugin. The extension that receives the credentials from Okta and fills the application’s form. It is the only component that touches the application’s sign-in page.

Okta org. Okta’s cloud service. It checks that the user has a valid session, evaluates policies, and releases the stored credentials only if everything passes.

Encrypted credential store. Where Okta keeps the usernames and passwords for SWA applications, protected with strong encryption. Credentials are not shown in the clear on the dashboard.

Sign-on and authentication policies. The rules that decide whether this user may launch this application under the current conditions and what proof is needed first.

Application sign-in page. The vendor’s own page, served from the vendor’s own website. Okta does not control it, which is why layout changes by the vendor can break SWA.

Web application. The target. It checks the password the usual way and creates its own session.

System Log. Okta’s diary, which records launches and credential events.

Before Okta can fill a password, the password must get into Okta safely. There are several ways this happens.

An SWA application needs a username and password in Okta’s vault. Where they come from depends on the credential mode that the administrator chose. We examine the modes in detail later. For now, here are the main routes into the vault.

How the vault protects them

Okta encrypts SWA credentials before storing them, using strong encryption with keys managed by Okta. Administrators generally cannot read a user’s stored password in the Admin Console. When the user launches the application, Okta decrypts the credential and sends it to the plugin over an encrypted connection, only if the user has a valid session and passes policy checks. The exact cryptographic design is Okta’s internal matter, so rely on current Okta security documentation rather than assumptions.

Where the password exists in the clear

Even with excellent vault protection, the password must exist in readable form at two moments. It exists in the plugin’s memory while it fills the form. And it exists, necessarily, inside the application’s own database or password check. So SWA cannot remove all risk. It minimizes the number of people who ever see the password and centralizes control over who may use it.

The click-to-signed-in journey, step by step.

sequenceDiagram
  participant U as User
  participant D as Okta Dashboard
  participant O as Okta
  participant P as Browser Plugin
  participant A as App Sign In Page
  U->>D: Click the app tile
  D->>O: Request launch of the app
  O->>O: Check the user session and the policies
  O-->>P: Send the stored credentials securely
  P->>A: Open the app sign in page
  P->>A: Fill the username and password fields
  P->>A: Submit the form
  A-->>U: The app opens and the user is signed in
    

Step by step

What the user notices

If everything works, the user sees a brief flash of the application’s sign-in page, then lands inside the application. The whole process takes a second or two. If the plugin is missing, Okta typically prompts the user to install it. If a policy requires a second factor, the user sees that prompt first.

How the plugin knows which box is the username, which is the password, and which button to press.

A web page is built from elements: boxes, buttons, labels. Each element can be found using a description of where it sits in the page and what it is called. The plugin uses such descriptions to locate the username box, the password box, and the sign-in button. For apps in Okta’s catalog, these descriptions are prepared and maintained by Okta. For custom apps, an administrator provides them.

The steps the plugin follows

Why it sometimes breaks

The plugin depends on the vendor’s page staying the same. If the vendor redesigns the sign-in page, renames the fields, or splits the form into two screens, the plugin may fail to find what it is looking for. Okta maintains the catalog integrations, but there can be a delay between a vendor’s change and the repair. For custom apps, the administrator must update the descriptions.

SWA comes in several shapes. Choosing the right one saves a lot of trouble.

Choosing the right type

The ready-made catalog covers a very large number of well-known applications. Before building a custom SWA integration, search the catalog. If the application is there, Okta has already done the field detection work and keeps it up to date. Custom integrations place that burden on you.

The most important SWA setting decides who creates and knows the application password.

When you configure an SWA application, you choose how credentials are provided. This decision shapes security, convenience, and workload. There are four common patterns, and the Admin Console words them in several slightly different ways. We describe them by meaning.

Choosing the right mode

flowchart TD
  A["New SWA application"] --> B{"Does the app support SAML or OIDC?"}
  B -->|"Yes"| C["Use federation instead of SWA"]
  B -->|"No"| D{"One account shared by a team?"}
  D -->|"Yes"| E["Shared credentials set by admin with password reveal off"]
  D -->|"No"| F{"Should users know the password?"}
  F -->|"No"| G["Administrator sets username and password for each user"]
  F -->|"Yes"| H["User sets their own credentials with reveal controls"]
    

The hidden power of not knowing

The strongest SWA setups are those in which users never learn the password. If the administrator sets a long random password and password reveal is turned off, the user can reach the application only by launching it through Okta. That means every access passes through Okta’s checks: multi-factor authentication, device rules, and logging. When the user leaves, deactivating them in Okta ends their route to the application, since they never knew the password. In contrast, when users choose their own passwords, they know them, and that knowledge outlives their Okta account.

One of the most valuable and most misused uses of SWA is sharing a single account among a team without sharing the password.

Many teams use a single login for a service. A marketing team may manage the company’s social media pages through one account. A small group may share a subscription to an industry database. Without a tool, the password passes through chat messages, is stored in notes, and is known by people long after they leave the team. Changing it means telling everyone again.

SWA with shared credentials solves much of this. The administrator stores one username and password for the application and assigns the tile to a group of users. Each user launches the app from Okta and is signed in, but never sees the password, provided password reveal is off. When someone leaves the team, the administrator removes them from the group. They lose the tile, and they never knew the password, so there is nothing to change.

What this solves and what it does not

Handling the first change

When you move an existing shared account into Okta, treat it as a handover. Change the password to a long random value as part of the move, since the old password has been shared widely. Store the new one in Okta, assign the group, and turn off reveal. Then record who the account’s owners are, so changes are controlled and the account is not forgotten when staff move on.

A stored credential has a life: it is created, used many times, changed, and finally retired.

The cleanup gap

The last step deserves emphasis. With federation, an application usually trusts Okta alone, so deactivating a user in Okta immediately blocks them. With SWA, the application keeps its own account and its own password. If the user knew the password, they could still sign in directly. And even if they did not know it, a dormant account may linger inside the application, a risk of its own. Good offboarding for SWA apps therefore includes disabling or deleting the application account, or rotating its password, where the application allows it.

What an administrator actually does, in plain language and in a sensible order.

The key settings to understand

The best SWA configuration is useless if the plugin is not on the user’s browser. Plan its rollout.

Because SWA depends on the plugin, deploying it is part of the project, not an afterthought. A large organization cannot rely on each person to find and install an extension. The usual approach is central deployment through the tools that already manage devices and browsers.

Deployment options

Practical considerations

Okta can protect the launch. It cannot protect the application’s own password page. That gap is the heart of SWA security.

Because SWA apps are launched from Okta, they can be covered by Okta’s sign-on and authentication policies. You can require multi-factor authentication before the plugin fills the credentials. You can limit launches to trusted networks or managed devices. You can demand fresh proof for sensitive apps. These protections are real and valuable.

The back door

But remember: the application still has its own sign-in page, and it accepts the username and password directly. Anyone who knows the credentials can go straight to that page and sign in without ever touching Okta. None of Okta’s protections apply on that path. If an attacker steals the password, perhaps from a breach of the vendor or from a user who knew it, they can walk through the back door, bypassing your multi-factor authentication.

flowchart LR
  U["User or Attacker"] -->|"Normal path"| OKTA["Okta with MFA and policies"]
  OKTA --> APP["Application sign in page"]
  U -.->|"Back door using a known password"| APP
    

Ways to narrow the back door

Whether a user can see the password, and how it changes over time, shapes the real security of an SWA setup.

Password reveal

Okta can allow users to view a stored SWA password after they prove their identity again. This is convenient when a user needs to type the password on a device without the plugin, such as a phone, or in a different tool. It is also a risk, because a person who has seen the password can reuse it, share it, or write it down. Once known, the password works at the back door described in the previous chapter.

Passwords that nobody types

When the administrator sets the password and reveal is off, nobody ever needs to type or remember it. That frees you to choose a long random password, which is far stronger than anything a human would choose. Where the application supports long passwords, use them. The best SWA password is one that no human has ever seen.

Rotation

Passwords should change when risk changes: when a staff member who knew the password leaves, when the application reports a breach, or on a regular schedule where policy requires it. Rotation in SWA has a catch. The password must change in two places: inside the application, and in Okta’s store. If these two get out of step, launches fail. Some integrations help keep the two in sync, and some applications can be updated through provisioning. For others, rotation is a manual two-step process. Decide in advance who performs it and how failures are handled.

When an application is not in the catalog, you can describe its sign-in page yourself. It is powerful, and fragile.

For applications not already in Okta’s catalog, administrators can create a custom SWA integration. You provide the address of the sign-in page and tell Okta how to find the username box, the password box, and the sign-in button on that page. If the page is simple, the result works right away. If the page is complex, you may discover that web pages are not designed to be filled by machines.

Common obstacles

Questions to ask before building a custom SWA app

A tour of the main risks in SWA and the defenses that fit each.

SWA is secure enough for many purposes when designed carefully, but it carries risks that federation avoids. Naming them is the first step toward managing them.

The concentration risk

Any system that stores many passwords in one place becomes an attractive target. Security teams call this concentration risk. The industry has seen incidents involving password vaults. For example, the 2022 incidents reported by a well-known consumer password manager showed how serious a vault compromise can be, even when the data inside is encrypted. A reputable identity platform invests heavily in protecting its stores, but you should still limit what you place there. Prefer federation, where no password is stored at all, for anything important.

Defense in layers

No single control closes every gap. Combine them. Okta’s policies protect the launch. Strong random passwords and hidden reveal protect the back door. Endpoint protection protects the fill. Central plugin management protects the extension. Monitoring and rotation limit the time any exposure can last. And a plan to move to federation removes the whole class of risk over time.

The plugin lives inside the user’s browser, which is one of the busiest and most attacked places on any computer.

The Okta Browser Plugin holds a powerful permission: it may read and change the content of web pages so it can fill forms. That permission is necessary for its job and attractive to attackers. Whatever protects the extension and its surroundings also protects your SWA credentials.

Risks around the extension

Defenses

SWA is a good bridge, but a bridge is not a destination. Here is a plan for moving on.

Because SWA keeps passwords in play and leaves a back door open, most security programs treat it as a stage to leave, not a final state. The pace depends on the vendor, the budget, and the sensitivity of the application. The migration is best treated as a continuous program with a prioritized list.

A prioritization method

A typical migration journey

You can only protect what you can see. SWA gives you some visibility, but not all of it.

Okta records activity in its System Log: application assignments, launches, and credential-related administrative actions. Exact event names depend on the release, so search the log for application launch and assignment events in your own org and learn what normal looks like. What the log cannot show is direct sign-ins at the application’s own page. For those, you depend on the application’s own logs and security features.

Signals worth watching

Metrics for the program

Other useful numbers include the percentage of SWA launches that fail, the number of custom integrations without a named owner, the share of SWA apps on the migration list, and the time it takes to repair a broken integration after a vendor change. Okta also offers reports on password health in user-managed SWA apps, which can reveal weak or reused passwords across your population, depending on your plan and release. Send logs to your security monitoring platform and route alerts to a team channel that someone watches.

Reliable shapes that many successful SWA programs share.

How the patterns fit together

The first pattern keeps SWA small. The second closes the back door as far as the technology allows. Group assignment keeps access tidy. Step-up and managed devices protect the launch. The offboarding checklist closes the cleanup gap. The register keeps the whole estate visible, and the migration plan ensures that SWA shrinks over time instead of growing quietly.

Mistakes seen again and again, so you can skip them.

Every sign-on method buys something and costs something. Here is the honest ledger for SWA.

Trade-offs to think through

Speed versus strength. SWA gets an app behind single sign-on in minutes, but federation is stronger. Use SWA for speed only when federation is truly unavailable.

Convenience versus the back door. Letting users reveal passwords is convenient but opens the back door. Hiding them is safer but makes plugin failures harder to work around.

Central control versus individual accountability. Shared accounts simplify management, but actions inside the application are not tied to a person. Weigh this against the risk of the app.

Catalog versus custom. Catalog integrations are maintained for you. Custom ones give flexibility but become your responsibility.

Plugin dependence versus coverage. The plugin makes SWA possible but requires deployment and device management. Without it, SWA does not work.

A checklist to read before launch and during every review.

Best practices

• Check for federation first. Use SAML or OpenID Connect whenever the application offers them.
• Search the catalog before building a custom SWA integration.
• Prefer administrator-set, long random passwords with password reveal off for sensitive apps.
• Assign through groups, so access follows roles.
• Add sign-on policies that require multi-factor authentication or managed devices before the fill.
• Deploy the official plugin centrally and restrict other extensions on sensitive machines.
• Include the application account in offboarding, and rotate shared passwords when people leave.
• Name an owner for every SWA app and every custom integration.
• Keep a register with credential mode, last rotation, and migration status, and review it quarterly.
• Monitor launches, credential changes, failure rates, and the application’s own sign-in logs.
• Test in a non-production org and in every supported browser before rollout.
• Plan the migration from SWA to federation, and ask vendors regularly about their roadmaps.
• Verify current Okta guidance before relying on any specific setting or browser.

Common mistakes

Six stories showing where SWA earns its keep, and where it needs care. These are illustrative teaching designs, not descriptions of any named company’s real setup.

Most SWA trouble falls into a few families. A calm checklist solves most of it.

A simple troubleshooting routine

Short answers to the questions that come up most often.

If you remember nothing else, remember the box below.

Secure Web Authentication is Okta’s practical bridge for applications that cannot speak modern single sign-on standards. By storing credentials in an encrypted vault and using a browser plugin to fill sign-in forms, it brings legacy and shared-account applications into the single sign-on experience, with central control over who may launch them. But it is a bridge, not a destination. The application still checks a password, which leaves a back door that Okta’s policies cannot guard. Used with care, SWA is valuable. Used carelessly, it becomes a quiet pile of passwords.