Search code examples
automated-testsauthorizationaccess-tokenfederated-identityapple-sign-in

What are the best practices for automated testing of "Sign in with Apple" (REST API)?


I'd like to create a set of automated tests that could run in a CI/CD pipeline. I'm struggling to understand how to verify the Generate and Validate Tokens portion of the "Sign in with Apple" flow (REST API implementation):

How can I verify that I'm properly handling the exchange of an authorization code for a refresh token? Considering that the authorization code is single-use and only valid for five mins, which in turns comes from authenticating. In my case authenticating requires 2FA.


Solution

  • END TO END TESTS

    A common starting point is to perform UI tests to verify logins in a basic way, in technologies such as Selenium:

    • These will automatically sign in test user accounts, to perform real logins and exchange of the authorization code for tokens.

    • After login the UI can proceed to test the application logic, such as calling real APIs using real tokens.

    COMPONENTS UNDER TEST

    Sometimes though, the OAuth related infrastructure gets in the way, eg if it is not possible to automate 2FA actions such as typing in a one time password.

    It is possible when working with this type of technology to mock the Identity system. One option can be to pretend Apple authentication has completed, while issuing your own mock tokens with a JWT library, with the same properties as the Apple ones.

    A key behaviour of course is to ensure that zero code is changed in UIs or APIs, so that they continue to run the same production logic, with no awareness that they are using mock tokens.

    HTTP MOCK ENDPOINTS

    The open source Wiremock tool can be a useful addition to your toolbox in this case, as in these API focused tests of mine. To use this type of tool, an automated test stage of the pipeline would need to repoint UIs and / or APIs to a URL that you are pretending represents Apple's identity system. So deployment work would be needed.

    DESIGNING THE INFRASTRUCTURE

    As always of course, it depends what you want to focus on testing, and which areas you are happy to mock. I recommend thinking this through end to end, thinking about both UIs and APIs. The important thing is to avoid situations where you are blocked and unable to test.