Third Party Authentication
Q2’s digital banking platform supports integrating 3rd party authentication and identity providers. This guide aims to discuss the various options and things that should be considered when evaluating using a 3rd party identity provider (IdP) such as Okta, Ping or Strivacity.
Inbound SSO vs Delegated Authentication
Q2 supports two main patterns for integrating an external IdP. The simpler option is Delegated Authentication. Delegated authentication uses the standard UI for login and other user management functions and uses an ExternalAuthentication adapter to communicate to the IdP.
This is different than the Inbound SSO option. The Inbound SSO option is where the end users will authenticate directly with the IdP’s UI. They will complete the login workflow in the IdP and at the end, the IdP will direct the authenticated user to Digital Banking. The supported model for Inbound SSO integration uses the Authorization Code Flow of the OpenID Connect (OIDC) specification.
Delegated Authentication
As discussed earlier, Delegated Authentication will utilize the Q2 UI for both end user workflows and also backoffice user administration. At it’s simplist, you will need to implement the Check Password function of an External Auth Adapter. This function will be executed everytime a user tries to login. The adapter will be passed the user name and password and is expected to return a True or False. A True will allow the user to login and a False will show an end user error message.
Beyond the initial check password, you should consider how the various other user administration functions will behave.
You have two options, the first is to utilize Q2’s UI and implement the supporting functions in the External Auth
adapter. The other option is to implement custom SDK pages for the various functions.
The functions to consider are:
Inbound SSO
Inbound SSO utilizes the full capabilities of the IdP’s UI login system. In this model the end user will login directly with the the IdP’s UI first. The IdP will take the user through it’s workflow (including MFA). When the IdP has completed it’s workflow it will redirect the user to Q2’s digital banking platform. The architecturual components and the sequence of events are outlined below. The user will no longer be shown Q2’s login form or MFA workflow.
Other Considerations
Beyond just the initial login, there are a few other considerations that need to be made when using the Inbound SSO setup.
Mobile App
Q2’s native iOS and Android apps will utilize the same Authorization Code Flow as above, but it will add Proof Key for Code Exchange (PKCE) (RFC7636) to the flow for added security. The mobile apps will complete the IdP’s login flow in the webview/browser on the mobile device. Once complete, the webview/browser will go away and the user will be taken into the mobile banking experience. Q2 utilizes the open-source package provided by Okta:
At this time, Q2 only supports mobile login using this SDK. If for some reason your IdP cannot work with these SDKs, please engage Q2 to discuss options.
At time of launch, it will be required to push a branch new mobile app with this SDK enabled and the standard login page removed. See note below on Production Launch.
Proof Key for Code Exchange (abbreviated PKCE, pronounced “pixie”) is an extension to the authorization code flow to prevent CSRF and authorization code injection attacks. The technique involves the client first creating a secret on each authorization request, and then using that secret again when exchanging the authorization code for an access token. This way if the code is intercepted, it will not be useful since the token request relies on the initial secret. The mobile app will store the refresh token in the Secure Storage of the mobile device. This refresh token is what will be used to instaite a digital banking session on susiquent logins, once the secure storage us unlocked using biometrics.
You can see a demo of the iOS experience here:
User Enrollment
When utilizing Inbound SSO it is important to consider what the User Enrollment (End 2 End Enrollment) workflow will be. Traditionally, there is a Q2 form that collects user’s information, verifies it on the core, and then allows the user to setup a username and password in the Q2 database.
When moving to Inbound SSO, the user creation needs to happen on the IdP first. Once that is complete, the
Caliper API Enrollment endpoint would need to be called by the IdP
(or some other system). This is important sequence as the Enrollment API needs to be sent the SSOIdentifier.
This SSOIdentifier is the unique ID for this user record in the IdP and what will be untilized to link the user from the IdP to the Q2
User record when logging in.
Step Up Authentication
Q2’s digital banking experience can require Multi-Factor Authentication in the middle of some workflows. Workflows that might require MFA are:
Login
High Risk Events
Transaction Authorization
In the near future, the Q2 SDK will support integrating an IdP providers MFA into these workflows. For now this is limited to Q2’s standard Secure Access Code and Token Workflows. Check back in Q4 of 2024.
New Account Opening
Similar to user enrollment, the account needs to be created on the core, then the user created in the IdP and then the last step is to created the digital banking user record. This sequence is important as each step depends on data from the previous step. The account opening flow should finish by calling the Enrollment workflow in Caliper API:
https://docs.q2api.com/docs/q2-caliper-api/3bwrohcnk5dgj-enrollment-guide
User Migration
Once the 3rd Party IdP setup is turned live to your end users, the IdP will need records of all of your users. Q2’s strong preference for how this will work is that the IdP will support calling the Caliper API’s Authenticate endpoint:
https://docs.q2api.com/docs/q2-caliper-api/branches/staging/4705b2e632fba-authenticate
The IdP should use this check any time they see a new user, validate the password using this API and Just-In-Time (JIT) provision the new user into the IdP.
There are other options if this is not possible, but this is Q2’s preference.
Production Launch
For Delegated Authentication, Q2 can support enabling this for specific Groups of users. This is controllable using a UserProperty.
For Inbound SSO, because of the mobile app dependency, it is only possible to do the entire customer base at the same time. There are no options for doing waves of users.
Non-Q2 Scope and Considerations
Q2’s system supports standard integration patterns with IdPs. We feel confident the Q2 system has enough flexibility to support most IdP setups and needs. That said, Q2 is not an expert in any of these Identity Providers. These IdPs are very complicated systems that have a tremendous amount of capabilities. It is highly recommended that a Financial Institution who is looking to implement a 3rd Party MFA look into engaging one of the systems integrators who are experts in the IdP of choice.