Controlling access to shared social media accounts with Okta

It is common for organizations to use accounts that are shared between multiple people to manage their social media presence. But the challenge for IT and Security teams is how to ensure proper use of these accounts. A social media account hijacking or credential compromise can cause significant damage to a brand’s image and reputation.

Only sharing the password with the social media team and never changing it is not an effective strategy. Some teams may opt to use a password manager to allow people in a team to access shared credentials, and that may be all that you need.

In this article we look at the ways Okta can help control access to shared accounts for social media services. They are, in increasing order of maturity:

• Use of Secure Web Authentication (SWA) Apps in Okta with shared accounts
• Use of manual SaaS Service Accounts in Okta Privileged Access
• Use of automated SaaS Service Accounts in Okta Privileged Access
• Use of Okta Shared Account in Okta Privileged Access for a federated shared account

We will explore them in the following sections.

Use of Secure Web Authentication (SWA) Apps in Okta with Shared Accounts

Okta traditionally deals with a mix of federated and non-federated accounts. Federated accounts leverage federated Single-Sign On (SSO) protocols, such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC), and don't involve passwords. Non-federated accounts are the legacy user ID/password accounts stored in the SaaS app repository and accessed via login prompts or passing credentials via HTTP headers.

When talking about accounts that are shared and used to administer platforms, we're normally talking about the latter. This is where Secure Web Authentication Apps come into the picture. The SWA mechanism will associate credentials with an application in Okta, and when a user selects the tile, the browser plugin will inject the credentials. 

The following shows a LinkedIn app defined in Okta with SWA as the sign on method.

Of all the options for credentials, the example is using "Users share a single username and password set by administrator." These are the shared credentials used to access LinkedIn by the marketing team. When the application is configured in Okta, the administrator must know and enter the username and password for the app. But the users do not need to.

When one of the assigned users clicks on the LinkedIn tile on their dashboard, the browser plugin will retrieve the stored username and password and inject it into the application sign on screen.

As with any application in Okta, assignments can be at the individual and/or group level.

Ideally you would assign access to an app using shared credentials via a group. You could then apply controls around group membership. You could use group rules to tie group membership to an attribute on the user profile (e.g., Department = Marketing).

But even better would be to use Okta Identity Governance controls to manage group membership. You can use the Request Access function to force users to request access to the group or app with an approval flow (e.g., manager approval) and time restriction (e.g., access only granted for two hours). You can use the Access Certification function to periodically validate those that have access still need that access.

Note that there is no automatic rotation of the password for the social media account; the value stored in Okta must remain in sync with what is in the app. When the app password is changed, the password stored in Okta must be updated to match. But only a single administrator needs to know this, and the updated password does not need to be shared out amongst a team. This is not a perfect solution, but provides better security than sharing the password amongst members of a team via email or on a piece of paper.

Use of manual SaaS Service Accounts in Okta Privileged Access

Okta recently introduced into Early Access a new feature to manage shared accounts for SaaS applications in Okta Privileged Access. This means that credentials for SaaS apps, like shared accounts used to manage social media platforms, can be stored in the Okta Privileged Access vault, and policy applied to control who can access the credentials and what process they need to go through to reveal the credentials (e.g., just-in-time access approval, supply multi-factor authentication).

This feature has two modes:

• Manual, where static credentials (username and password) are stored in the vault and reflect the credentials in the app. When the app credentials are updated, the vault needs to be updated to match.

• Automatic, when the Okta Integration Network (OIN) integration for the app supports provisioning, so Okta Privileged Access can be the manager of that social media accounts password.

Social media platforms like facebook and linkedin rely on the manual approach — you need to store static credentials and setup policy to control how they can be revealed.

As Okta will not be performing the sign-on for the manual app, it is defined as a dummy app in Okta (i.e., a bookmark app, and hidden from the users' dashboards). Then the shared credentials are stored as Service Accounts in Okta.

With the shared account stored in Okta and assigned in Okta Privileged Access, users (based on policy) can reveal the username and password.

They use the Okta Privileged Access UI to find the SaaS app.

Then select the account.

There may be controls associated with the account, such as a just-in-time access approval or multi-factor authentication. Then they can reveal the credentials, which can be copied and pasted into the login form for the social media app.

Compared to the earlier SWA approach, this approach does reveal the password to the end user, and as the password is not automatically rotated, there is a risk of them writing it down and sharing. You would need a process to periodically change the password in the social media platform and update the copy in the vault.

This approach also means more control can be applied to accessing the credential. The SWA approach was restricted to group membership controls, whereas this approach can also apply additional controls such as MFA and access approval.

This approach does not yet have the browser plugin for automatic injection of credentials that the SWA approach does.

Use of automated SaaS Service Accounts in Okta Privileged Access

The second option for using SaaS Service Accounts in Okta Privileged Access is where the password for those accounts can be managed from Okta via the Okta Integration Network integration for the app. It relies on:

1. It having an integration that supports SCIM
2. That integration has been tested to support the password rotation function with Okta Privileged Access.

The current list of SaaS apps that support this automatic management of passwords is here. At the time of writing (Jan 2025) the only social media app in the list is Workplace by Facebook (although you might consider Google Workspace, and some of the others, as managing social media access).

The mechanism is the same as above, except that the password for the shared account will be rotated (changed in Okta and provisioned to the app) after its use and on a cycle. This way only Okta Privileged Access knows the password. The user will reveal the password to perform a copy and paste into the login prompt for the app, but once they’ve used the password it is replaced, so there’s no value in writing it down and sharing it.

As Okta Privileged Access is managing the password and rotating it after use, it can also employ an exclusive check out, so only one user can access the password at a time. In addition to restricting access to the shared account to one user, it means that any audit trail can tie an individual Okta user to the actions of the shared account.

This is obviously a more secure approach than the previous two as there is no static password that can be shared around.

Use of Okta Shared Account in Okta Privileged Access for a Federated Shared Account

The final approach that can be used is where the account used to manage the social media platform is a federated account (no password, federated single sign-on is used to securely connect to the account) that is shared. There is no password to be shared around, but access to the account requires an Identity provider like Okta to initiate the single sign-on and pass over the appropriate tokens. But how do you manage access to these accounts in Okta?

You could have a dedicated user in Okta that maps to the social media app, and that user is the only Okta user who can access the app. The only way users can access the social media app is to login to Okta as that special user and click the tile. But then are we back to the problem of having a shared password to access the special Okta user account? Not necessarily.

The new SaaS service account feature also covers Okta accounts. You could configure the Okta social media user and Okta Privileged Access as above, so that the credentials to log into Okta as that social media user are revealed in the same way that we saw above. The user would go to Okta Privileged Access, reveal the special Okta social media user account and use the credentials to log into Okta as that user, click the social media tile and be signed on to the app. When they finish they check in the Okta account and the password is rotated.

You could theoretically put multiple federated social media accounts under the one Okta account and manage access in this way.

See Managing and Using Okta Shared Accounts with Okta Privileged Access for more details on this mechanism.

In this approach, you’re not managing the password of the social media account (as it’s federated and doesn’t have one) but rather managing the password of the Okta account that allows you to SSO into that federated social media account.

Conclusion

There is a spectrum of approaches to managing shared social media accounts in Okta. 

At one end we have the existing Secure Web Authentication (SWA) mechanism that allows a shared username and password to be stored by the administrator and injected into the app login by the browser plugin. This has some security limitations. 

Then there is the use of the new SaaS Service Accounts feature in Okta Privileged Access that will store social media credentials in the vault and allow them to be checked-out by authorised users with appropriate controls, like requiring a manager's approval at the time they need to use the account. Where the integration supports password rotation, Okta Privileged Access will manage the password of these accounts.

A final approach is where the social media platform supports federated accounts, but you want to share these accounts with multiple users. In this case you could create a special Okta user for these federated accounts and use the Okta Privileged Access Okta Service Accounts feature to grant access to these special Okta users as needed, with the appropriate controls.

These options represent a range of security considerations and the approach you choose will be based on the social media platform, its approach to shared accounts, and the risk appetite of your organization. Even if you use a password manager, there may be value in the new Okta Privileged Access features for improved security and reduced risk.