What is the best practice for managing non-human accounts (service accounts) with SAML? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Ben BezarkBen Bezark 

What is the best practice for managing non-human accounts (service accounts) with SAML?

Specifically in G Suite, Box.com and Salesforce we have certain accounts that are not tied to users, that are needed mostly for integrations or API access. If we implement SAML requirements on these, is there a way to allow only selected accounts to be accessed directly by password, and require SAML generally?
Costel CurcaCostel Curca (Okta, Inc.)
My name is Costel from Okta support.
All Admin accounts used for API access/provisioning or to access the Admin Portal don't go trough SAML by design.These accounts are have access trough the username/password auth system.
For example in G Suite only an admin account can login to admin.google.com with the username and password, any other user will be redirected to Okta for authentication.
Ben BezarkBen Bezark
Thanks for your response. I realize that for G Suite, admins can get in with PW auth, but I am asking about other accounts, for example a non admin account that is used as a support email address.

Is it true for all applications that admin users can log in directly with a password without going through SAML, even if the application is set to require SAML? I saw the admin backdoor for G Suite, but it was not clear that is the case for Salesforce and Box.

Av ShchAv Shch
We have integrated SSO between G-Suite and Okta for SSO. The issue is we still have to provide applications access for applications (MoJoNetworks, Okta user provisioning for G-Suite) to G-Suite API's.
Based on G-Suite implementation, users with regular privileges (non-admin) are forced to authenticate via interactive web-based sign-in  process provided through Okta.
This process seems to be visible to regular G-Suite users and can not be used by service (applications) accounts for interactive sigin.
We are required to use 2FA process to authenticate service accounts into G-Suite to ensure secure communication and prevention from credentials hijacking of the privileged G-Suite accounts.  It does not appear to be possible with Okta to assign an OAuth token to an account. Based on Google tech support, this option is available from G-Suite side.

As a work around we had to elevate the permission for the service/application accounts to domain priveledges to exclude from SAML authentication on G-Suite side. This is causing a security concerns over the application/service accounts with admin access to G-Suite API's w/o 2FA.