- The end-user is a visitor on the partner's website website: he only interacts with the partner's website.
- The website displays a form to the user, along with a
ocapi.jslink that will render the challenge
- The ocapi service is a REST API that both the user's browser and your website will use to get challenges and validate them.
- The end-user visits the partner's website with his browser: he gets an HTML page and our
ocapi.jspayload, alongside some public credentials to identify which challenge will be later served.
- His browser renders the form, and the
ocapi.jsscript makes an HTTP
GETquery on the Ocapi instance to get a new challenge.
- The challenge is created, sent as a JSON payload to the browser.
- The challenge is then properly rendered by
ocapi.json the end-user browser.
- The end-user can start to fill the partner's form as soon as it's displayed, but he must fill in the Ocapi form to validate the form.
- Once the user click on the Ocapi validation button, an HTTP
POSTrequest is triggered to check if the user's answer is valid.
- If the answer is invalid, a new challenge is automatically created, and the user must retry.
- If the answer is valid, the user can submit the full form.
- The partner's website must now check that the challenge is indeed valid, and makes an authenticated
GETquery on the Ocapi instance
- The Ocapi instance sends back a simple state message in a JSON payload.
- The partner's website can then proceed the form (if the state is valid), or reject it entirely.
All HTTP requests between the end-user browser and the ocapi instance do not need any form of authentication: a user can only:
- create a new challenge
- update this challenge with his answer
The partner's website can authenticate itself using a JSON web token with an HMAC signature (using a provided secret key), so it can:
- check a challenge provided by its user is valid.
You can view the OpenApi specification here.