SSO works by creating an integration between a client's IdP and Apply via the OAUTH protocol. The handshake passes along key user information, including the UID. The key role of the IdP is to verify, for Apply, that the users information is known, and correct account details have been provided.
Due to the technical nature of implementing an SSO Integration, and the vast number of authentication services that clients can have, Apply requires there to be a technical expert on the client’s end who has a background or strong knowledge of SSO.
To begin setup:
|Consumer Key (Client ID)||API Key associated with the software you are authenticating with (identification for the client). It must be unique across all clients that the authorization server handles.|
|Friendly Name||Provide a title for this OAuth integration. This name will be shown to your users.|
|OAuth version||1.0 or 2.0, depending on your version. Ensure that you know which version you are using!|
|Authorize URL||Taken from your resource server after the user has been authorized. This can be considered a log-in point to the software identifying server. https://example.com/oauth/authorize|
|Access Token URL||An object that contains the security identity. An access token is the string used when making authenticated requests to the API. https://authorization-server.com/token|
|Access Token URL (Method)||The HTTP method to use when communicating with the above Access Token URL|
If Version 1.0 Authenticate URL: The endpoint for the authorization server, which retrieves the authorization code.
If Version 2.0 Profile URL: Leads to the profile that you are providing SM Apply Access to. You will have control of what the system has access to.
In addition to testing that the sign-in components are working correctly, full tests through complete applications should be run using users coming in through the SSO, testing all potential submissions, links, tasks and resources ensuring everything is working as desired.
If issues are discovered during initial testing of the SSO there are some key pieces of information required to help resolve the issue: the type of user being tested, the login credentials for that user, and the error message (if one is displayed). Screenshots of error messages are always encouraged.