OAuth stands for the Open Authentication standard and is a framework that allows a website to pass authentication of a user to a third-party provider.
The most common implementation of OAuth is a website login page with the option to sign in with your Facebook, Google, Microsoft or other provider account.
(Show picture)
When a user selects the option to sign in with another OAuth provider, the website passes the user to that provider’s sign in page. The provider verifies the identity of the user and then redirects the user back to the original web site along with information about the user identity. The original web site trusts the provider properly authenticated the user and accepts the user identity that is being presented.
OAuth Example
If you choose to log into CostGuard with your Microsoft Live account then the process flow would work very similar to this:
Go to costguard.idibilling.com and click the Log In With Microsoft Live button.
(Show picture)
The Microsoft Live log in page is displayed. Enter your Microsoft credentials and click Sign In.
(Show picture)
Microsoft verifies your identity and then redirects you back to CostGuard along with an OAuth token.
The token contains information such as your Microsoft account name, account email and a user identifier for you that is unique to Microsoft.
CostGuard then reads in your Microsoft identity and matches your information to an account in the Security database.
Once your account is found, CostGuard accepts that Microsoft has already verified who you are and will automatically log you into CostGuard with your user account.
Close the pop-up and the Welcome page is then displayed in your original browser window.
Enabling OAuth Support Basic Steps
Step 1: Ensure your User Accounts are Created.
More
Single Sign-on still requires that a user has an account in both Office 365 and in CostGuard. Any password configured in CostGuard will not be used; however, all the permissions to CostGuard modules still have to be assigned to the account in Security. In addition, CostGuard will still check account settings such as activation date or account disabled.
The User ID’s between the two systems do not need to match when users go to link their Office 365 accounts to CostGuard (see Step 4 below) then having the email addresses be the same makes this process simpler.
Step 2: Select an OAuth Provider
More
The IDI platform supports integration with any Authentication Provider who supports the Open Authentication Standard 2.0 (OAuth).
More
Notable OAuth Authentication Providers include:
Cloud Foundry
Dropbox
Evernote
Google
Intel
LinkedIn
Microsoft (Live, Office365, Active Directory)
Salesforce
Trello
ZenDesk
This is just a sample list of providers. Other software vendors and platforms support OAuth as well. To see if your existing vendors support OAuth you will need to check their documentation and resources to see what capabilities they offer.
The IDI platform supports two providers out of the box
Salesforce
Microsoft Live.
Additional providers, such as Office 365, can be added however since the configuration often requires customer specific information they must be added on an individual basis.
Getting a new Authentication Provider added can be initiated by contacting your Account Manager or Project Manager.
The IDI platform supports both global and company specific OAuth providers.
Global providers are added by IDI for use by any customer. Once a global provider is in the system, it will appear as an option for all company administrators. They can choose to enable support for it or not.
Company specific providers are created for use by an individual customer and will be visible only to their users.
Providers are added for individual customers via an IDI Professional Services work order.
IDI has the ability to add new providers via configuration (no code changes), however, the complexity of the configuration requires a work order to cover the registration, configuration, and verification of the OAuth link between the two systems.
Integrating Existing Identity Systems
Customers using Windows Active Directory have the ability to create an OAuth end-point using the Active Directory Federation Services feature in Windows Server.
Microsoft also supports hosted Active Directory Identity Management as an Azure Service.
Development teams have the ability to create their own OAuth end-point in front of any identity system; however, several cloud companies like Okta, Ping Identity and OneLogin provide this type of service already.
Step 3: Enable OAuth Support
More
Company administrators can enable OAuth log-in capability for their company on a
domain-by-domain basis. This is supported via the Authorization Providers option in the POLICY menu. Selecting this option displays the Allowed Authorization Provider form.
(Show picture)
Click the add button to open the Add Allowed Authorization Provider window.
Select one of the available Authorization Providers from the drop down list.
(Show picture)
Show On Log In is checked by default. This setting determines whether the option to log in with the provider is displayed on the IDI platform Log In screen.
Uncheck this box if you do not want this option displayed on the IDI platform Log In page.
Click Add to add the provider to the domain as an optional authorization provider.
Note
The eye icon indicates that the provider is visible on the log in screen.
Admins have the option to edit the provider (e.g., change the check box setting) or remove the provider.
(Show picture)
Step 4: Link user accounts
More
To let users log in with an external account, that account must be linked it to their IDI platform account. There are two options for doing this: