Google OAuth 2.0 and OIDC SSO
Agiloft supports single sign-on (SSO) with Google OAuth 2.0 and OpenID Connect (OIDC) for authentication and identification. This article guides you through the steps to create a Google OAuth client for Agiloft and then configure your KB to route SSO logins to Google as the identity provider (IdP). It also includes instructions on how to log in with SSO after the integration and make sure other users log in with SSO as well.
Prerequisites
- To complete the setup, you need admin access to the Google Cloud Console with permission to configure new applications.
- Unlike SAML 2.0 SSO, where user records don't need to pre-exist in Agiloft because authenticated SSO logins can trigger automatic record creation, users can't log in with OAuth 2.0 SSO unless they already have a user record in Agiloft. Make sure each user who will use SSO has a user record in Agiloft. In addition, make sure the data in the record meets at least one of the following conditions. These conditions are used to match users for identification in Google:
- The user's Email address in Agiloft matches their Gmail address.
- The user's Login in Agiloft matches their Google login.
Set Up SSO in Google
Follow the steps below to create a project in Google and add Agiloft as an OAuth web client.
- Log into the Google Cloud Platform Console as an administrator and go to APIs & Services.
- Create a new project:
- At the top of the screen, click the current project name to open the Select a resource dialog box.
- In the dialog box, click New project.
- Enter a project name, such as Agiloft SSO, and change the Organization and Location if needed.
- Click Create. After the project is created, make sure it's selected at the top of the screen.
- Next, create the consent screen for the new project. For information on consent screens, refer to Google's documentation on setting up consent screens.
- In the left sidebar, click OAuth consent screen, then click Get Started to configure the project.
- Under App information, enter the name of the application, such as Agiloft.
- In User support email, select the email address where users can get support, then click Next.
- Under Audience, select Internal to limit access to the app to users within your organization, then click Next.
- Under Contact information, enter the email address where Google should send project notifications, then click Next.
- Agree to the Google API Services User Data policy and click Continue.
- Click Create. The OAuth Overview is displayed.
- Next, click Branding in the sidebar. For information on branding, refer to Google's documentation on managing OAuth app branding.
- For the App domain settings, you can enter the following URLs for Agiloft's home page, privacy policy, and terms of service:
- For Authorized Domains, add each applicable domain:
- Add your company domain.
- If your KB is in the Agiloft domain or you included Agiloft URLs in App domains, add
agiloft.com
. - If the domain for your KB is not
agiloft.com
or your company's domain, also add the KB domain.
- Click Save to save the changes.
- Next, create the Agiloft web client:
- Click Clients in the sidebar, then click Create Client at the top of the screen.
- For Application type, select Web application.
- Enter a Name for the client, such as Agiloft SSO Client.
- Leave Authorized JavaScript origins blank.
- Under Authorized redirect URIs, click Add URI and enter the following URI:
https://DOMAIN_NAME/ui/oauth20sso
. Replace DOMAIN_NAME with the domain for your KB. For example:https://example.agiloft.com/ui/oauth20sso
. Copy this URI to a note to use later in the setup. - Click Create.
- Once the client is created, copy the Client ID to your note. In addition, view the client details and copy the Client secret value to the note.
- Complete any other optional client configuration as needed. Agiloft client does not require specific Data Access scopes.
Now that the application is configured in Google, you can set up SSO in Agiloft.
Set Up SSO in Agiloft
Follow the steps below to set up SSO in Agiloft.
- Go to Setup > Access > Configure OAuth 2.0 Profiles and click New to add a profile.
- Leave the "Use full OAuth account name as a KB login name / email" checkbox selected.
- Enter a name for the OAuth 2.0 provider, such as Google.
- For the role of this OAuth 2.0 Provider, select OAuth20_SSO.
- Complete the remaining fields:
- Redirect URI: Overwrite the default value with the Authorized redirect URI you noted when you set up Google.
- Client ID / Application ID / Consumer Key: The Client ID from your note.
- Client / Consumer Secret: The Client secret from your note.
- Authentication URI: Enter Google's authentication endpoint:
https://accounts.google.com/o/oauth2/auth
- Token URI: Enter Google's token endpoint:
https://accounts.google.com/o/oauth2/token
- Click Finish to save the profile.
Agiloft is now configured to allow SSO with Google OAuth 2.0 and OIDC. Proceed to Log in with SSO for details on how to log in.
Log in with SSO
Once the integration is complete, users can access Agiloft with OAuth 2.0 SSO. Follow the steps below to create the OAuth SSO login URL and share it with your users. For system-generated email hotlinks, you don't have to make any changes to accommodate SSO and non-SSO users. Based on a user's login method, Agiloft manages which hotlink URL they receive in email. Each time a user logs in, the system sets a hidden SSO Authentication Method field in the user's record. If a user logs in with a standard username and password, the value is https://DOMAIN_NAME/ui/oauth20sso?project=KB+NAME
https://example.agiloft.com/ui/oauth20sso?project=Example+KB+Name
STANDARD
. If a user logs in with OAuth 2.0 SSO, the value is OAUTH20
. This value determines whether email hotlinks go to login.jsp
or oauth20sso
. Don't edit a user's SSO Authentication Method because you might prevent them from accessing the system.
Force SSO Login
To force users to log in with SSO, you can prevent them from accessing Agiloft with their username and password. Follow the steps below to make the Password field optional in the Employees table and then remove passwords for employees who should log in with SSO. Now, users whose passwords were reset can only log in with SSO. If you also allow some external users to log in with SSO, repeat the process for the External Users table.$global.null
and click Next.