Users can use Single Sign-On (SSO) to log into MyMoveworks and access all applications from one portal. Your organization should have an SSO provider, which controls how you log into most of your applications.

We have detailed guides for common SSO setup experiences. Please ask your SSO administrator to complete the right guide for your organization.

• Okta
• Microsoft Entra (fka. Azure Active Directory)
• OneLogin

We also have generic guides if you do not see your SSO provider listed here

• OpenID Connect (OIDC)
• Security Assertion Markup Language (SAML)

FAQ

How do I grant users access to applications once SSO is set up?

There are two steps required to grant a user access

1. Add them to the application in your SSO provider.
2. Grant the user access to MyMoveworks applications in the Roles & Permissions module.

✅

TIP: Integrate SSO Provisioning with Moveworks

When your users ask for access to MyMoveworks, you can send them to your Copilot. From there, you can rely on our plugins to grant the user access.

• You can use our Software Access plugin to integrate SSO provisioning directly with Moveworks
• You can use our Forms plugin if you want to manage provisioning through your ITSM.
• You can build your own plugin with Creator Studio.

Can I log into MyMoveworks without SSO?

No. You can only access MyMoveworks experiences over SSO.

How does Single Sign-On (SSO) work?

To make SSO possible, an identity provider (IdP) such as Okta or OneLogin must provide a central authentication server, which multiple applications can use to verify user identities. The authentication server validates user identities and confirms their identity to the application by providing an encrypted access token.

When a user first logs into an application, they are redirected to the IdP and are asked to provide their credentials, typically username and password.

For example, when signing in to an application, users can use two different identity providers to login: Application specific user name or Google. When users select one of the options, they are redirected to the relevant IdP to perform authentication.

The authentication server checks the user’s credentials against its central user directory, and if they are valid, starts an SSO session. Subsequently, the user can access the application for a predetermined period without logging in again.

When the user attempts to access another application from the trusted group, there is no need to request credentials again. The application requests authentication from the IdP, leveraging the open SSO session. The IdP provides an access token, and the application grants access to the user without showing the login screen again.

Here is an example of an SSO workflow:

1. The user requests a resource from their desired application/website.
2. The application/website redirects the user to the Identity Provider for authentication, using SAML, OpenID Connect, etc.
3. The IdP authenticates the user and passes a token to the SSO server.
4. The SSO server delivers the token to the application.
5. The application grants access to the user.