Workflow
-
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.js
link 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.
Steps
-
The end-user visits the partner’s website with his browser: he gets an HTML page and our
ocapi.js
payload, alongside some public credentials to identify which challenge will be later served. -
His browser renders the form, and the
ocapi.js
script makes an HTTPGET
query 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.js
on 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
POST
request 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
GET
query 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.
HTTP Requests
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.