How to Set Up Okta as a 3rd-Party IdP for Amazon Connect (From Salesforce Service Cloud Voice)

Why we needed this

• One login, less headache — thanks to SSO.
• Keep all user management tidy in Okta (no juggling between systems).
• Way simpler to control who gets access to what, all from one place.

Basically, fewer clicks, fewer passwords, and a whole lot more sanity for both IT and agents.

What we decided to do

• Agents start in Salesforce Omni-Channel.

• When they launch the voice console, it redirects them to authenticate via Okta.

• Okta then sends back a SAML assertion with extra attributes we need (like their Amazon Connect username and role).

• Boom — they’re logged into Amazon Connect.

The special twist: custom attributes

We needed to tell Amazon Connect who the user is and what role they should have.

So, in Okta, we created two custom user fields:

• connect_username (maps to the Amazon Connect user name)

• connect_role (so we can assign SAML Role and IDP to use at AWS side )

These fields goes inside the SAML assertion as custom attributes, so Amazon Connect knows exactly what to do.

How we set it up step by step

1. Create custom attributes in Okta

   • Go to Directory → Profile Editor → Okta user profile.

   • Click Add Attribute.

     • For connect_username: give it a display name and variable name, like connect_username.

     • For connect_role: same idea.

   • Save.

   Now each user profile has these fields ready.

2. Populate the fields for your users

   Go to each user under Directory → People, edit their profile, and set:

   • Connect Username: (whatever matches their Amazon Connect username)

   • Connect Role

   
   
3. Set up the SAML app for Amazon Connect in Okta

   we made a new SAML app integration in Okta:

   • Single sign on URL: 

     Example : https://us-west-2.signin.aws.amazon.com/saml

   • Audience Restriction (SP Entity ID): Internal name of your Contact Center

   Then under Attribute Statements, we added: This ensures when Okta sends the SAML assertion, it carries our custom data.

   

4. Connect it in Amazon Connect

   In the Amazon Connect console under Users → Identity Management → SAML, we:

   • Added Okta as a new IdP by uploading the metadata.

5. Tie it all together with SCV in Salesforce 

    

   Take the Metadata URL from Okta and paste it in the `Identity Provider URL` by enabling Third-Party Identity Provider at Contact Center UI.

   

Wrapping up

Hope this gives you a clear, real-world guide on wiring up Okta as your IdP for Amazon Connect from SCV.

The best part? You’re not limited to Okta. You can explore similar setups with other identity providers like Azure.

So go ahead, test it out, tweak it to fit your needs, and unlock a truly seamless SSO experience for your contact center teams. Happy building!