6.1. Broker OAuth Conformance Testing
This section details the key conformance tests performed by Spotware Systems prior to enabling OAuth and InApp flows within production applications. Conformance testing achieves the following objectives:
-
Users are provided with high-quality experiences and flows.
-
The deployment of broker OAuth flows and InApp controls complies with a single formally-defined implementation standard, reducing security risks.
-
Brokers can take full advantage of the opportunities provided by Spotware’s OAuth and InApp flows, benefitting user conversion rates and revenues.
-
Spotware’s technical support team can quickly and accurately diagnose any issues that may arise on the client’s side.
All conformance tests are performed within standard working hours by Spotware Systems’ technical specialists.
6.1. Broker OAuth Conformance Testing¶
The following table lists Spotware’s conformance tests for the deployment of broker OAuth flows.
| Test No. | Name | Required? | Test Justification |
|---|---|---|---|
| API Security and Access | |||
| 1 | All REST API calls are made to secure endpoints using the https protocol. | Yes | To ensure the safety of sensitive data (e.g., trader login IDs), all calls need to conform to the latest web security protocols. |
| 2 | All API calls are made to and from servers in possession of valid server certificates. | Yes | |
| 3 | The broker’s client area can successfully generate an authentication token for the cTrader backend. | Yes | To protect traders and brokers, only properly authenticated systems can send successful requests to brokers’ client areas. |
| 4 | The broker’s CRM system checks the validity of the authentication token used by the cTrader backend and can prevent access if the token is invalid. | Yes | |
| Login/Signup Screens | |||
| 1 | The screens have responsive designs. | Yes | All users must be provided with high-quality UX regardless of their preferred cTrader application. |
| 2 | None of the screens mentions ‘cTrader ID’. | Yes | cTrader ID is not created via the OAuth flows, preventing users from logging in to non-intended cTrader applications. |
| 3 | The screens support both light and dark themes. | No | The screens must reflect users’ preferred application themes to avoid disruptions to UX. |
| 4 | The screens support different languages. | No | All users must be able to access the new flows regardless of their preferred display language. Although this test is not mandatory, passing it is highly recommended for offering a high-quality UX and boosting user conversion rates. |
| 5 | The screens are neatly organized with no unnecessary UI elements. | Yes | To maximize conversion rates, all screens must conform to the UI standards of the native application. |
| 6 | The screens mention the correct legal entities. | Yes | To avoid user confusion, screens cannot mention any brands unrelated to application branding. |
| 7 | No pop-up messages appear on any screen. | Yes | Pop-up messages disrupt the UX and may cause unforeseen technical issues. |
| 8 | The relevant screens accept the partnerId parameter and can pass it to the broker’s backend. | Yes (but only if the broker has referral programs) | Proper partner attribution is impossible without accepting and passing the relevant parameter. |
| 9 | Users can switch between login/signup screens when appropriate. | Yes | For smoother flows, users should be able to perform actions related to login/signup without closing the application. |
| Internal Screens Shown During the Signup Flow | |||
| 1 | None of the screens mentions other trading platforms. | Yes | For obvious reasons, none of the OAuth flows should result in the creation of user accounts inside other trading platforms apart from cTrader. |
| 2 | Tests 1-7 from the ‘Login/Signup Screens’ category. | Depends on the original test | All screens must conform to the UI requirements established above to avoid disruptions to the UX. |
| 3 | The signup process is completed quickly. | No | To maximize users’ trading times, the authorization flow should be completed as quickly as possible. |
| 4 | The broker’s terms of service are compliant with the GDPR. | Yes | To avoid compliance risks, the broker’s terms of service must reference the GDPR and acknowledge that clients’ data is passed to Spotware Systems. |
| Backend Functionality | |||
| 1 | The partnerId parameter contains accurate information about the broker’s partner. | Yes (but only if the broker has referral programs) | As referral programs generate significant revenues for all parties, their integration into the OAuth flows is essential to deployment success. |
| 2 | User creation works correctly. | Yes | User creation constitutes a flow essential to Spotware’s OAuth solution. |
| 3 | The OT token is correctly generated and exchanged as outlined in the user flows. | Yes | Without these processes working correctly, it will be impossible to ensure the successful deployment of the outlined OAuth flows. |
| 4 | All tokens generated by the broker’s backend office must be different for different users. | Yes | |
| 5 | The OT token expires one minute after its generation. | Yes | |
| 6 | User authorization via access tokens works correctly. | Yes | |
| 7 | As per the relevant flow, users are correctly redirected to the chosen success URL that accepts the needed parameters. | Yes | |
| 8 | Users can change their emails; upon performing this action, the relevant request is sent to the cTrader backend. | Yes | Users must be provided with an option to change their emails to conform to the industry-wide UX standards. |
| Other | |||
| 1 | cTrader Web is embedded into the broker’s CRM system; additionally, there is an easily accessible button to launch this application. | Yes | If a user chooses to register within their broker’s client area first, it is crucial to provide them with an option to launch cTrader quickly to boost conversion. |
Last update: September 26, 2022