CorePass
Start integrating

CorePass Connector

CorePass login live in under five minutes.

CorePass Connector gives your application a passwordless login built on OAuth 2.0: a person signs in by scanning a QR code with an application they already carry, and your servers store no password, no email address and no phone number. The same integration requests verified identity data, approved field by field on the person's own phone before any of it reaches you.

  • OAuth 2.0
  • No stored credentials
  • KYC and KYB
  • Signed webhooks

Sign in

Scan with CorePass

Or tap the link on a phone. The approval happens in the application, and your page never sees a credential.


  • No password to set or reset
  • No email address to confirm
  • No phone number to hold

Quickstart

Four steps, and the login is live.

Nothing here is a sketch: every snippet below is the code the integration actually ships with, and the only thing standing between an empty project and a working sign-in is a client CorePass issues you. Verified identity data is the same integration, one call further on.

  • 1 Register your application 1 minute
  • 2 Drop the QR code into your login page 1 minute
  • 3 Handle the redirect back 2 minutes
  • 4 Make your first call 1 minute
  • Total 5 minutes

Open the full quickstart

  1. 1 minute

    Step 1: Register your application

    CorePass issues the client your application authenticates with and registers the redirect URI it comes back to. Everything else lives in your own environment, so there is nothing to configure on the page a person actually sees.

    .env
    # The credentials CorePass issues for your client, in your own environment.
    COREPASS_GATEWAY=https://auth-develop.corepassdev.eu
    COREPASS_CLIENT_ID=<your client id>
    COREPASS_CLIENT_SECRET=<your client secret>
    COREPASS_REDIRECT_URI=https://your.example/callback
    COREPASS_SCOPE="openid offline offline_access"
  2. 1 minute

    Step 2: Drop the QR code into your login page

    The login page is yours to design; only two elements are fixed. A person on a desktop scans the QR code, a person on a phone taps the link, and login.js polls for the approval and redirects when it arrives.

    login.html
    <!-- The file has to be called login.html, and its sign-up twin register.html. -->
    
    <img alt="{{.link}}" src=" data:image/png;charset=utf-8;base64,{{.qrcode}}" />
    
    <button>
      <a class="link" href="{{.link}}"> Login with CorePass </a>
    </button>
    
    <form id="login-form" method="POST">
      <input type="hidden" name="challenge" value="{{.challenge}}" />
      <input type="hidden" name="identifier" value="{{.identifier}}" />
      <input type="hidden" name="session" value="{{.session}}" />
    </form>
    
    <script src="static/js/login.js"></script>
  3. 2 minutes

    Step 3: Handle the redirect back

    The person returns to your redirect URI with an authorization code. Exchange it with the CorePass app-auth library, and the token you get back carries the person's Core ID — their address in the Core ecosystem, and the identifier you key your own user records on.

    Your redirect URI
    GET /callback?code=<authorization code>&state=<your state> HTTP/1.1
    Host: your.example
  4. 1 minute

    Step 4: Make your first call

    The login is now working, and the same Core ID is the key to everything else. Ask the connector which of the fields you care about this person has verified, and you have the answer your onboarding flow needs before it asks them for anything.

    POST /api/v1/blockchain/verified
    curl --request POST \
        --url https://auth-develop.corepassdev.eu/api/v1/blockchain/verified \
        --header 'Content-Type: application/json' \
        --data '{
            "user": "ab22b1671b4f7ccc0b16a87514adde84513b6348232e",
            "items": ["IDCARD_DOB", "DRIVER_LICENSE_DOCUMENT_NUMBER", "EMAIL"]
        }'
    200 OK
    {
      "verifiedItems": ["EMAIL"],
      "unVerifiedItems": ["IDCARD_DOB", "DRIVER_LICENSE_DOCUMENT_NUMBER"]
    }

How it works

A sign-in is an exchange between two devices.

Your server is only told the result. The person's credentials never leave the application on their phone, which is what removes the password, the reset flow and the stored contact details from your side of the integration at once. What your application receives is an authorization code, and behind it a token naming the person by their Core ID.

  1. Your login page

    shows the QR code and the mobile link the connector generated for this session.

  2. The CorePass app

    scans it, and the person approves the sign-in on a device only they hold.

  3. The connector

    settles the approval and redirects the person back to you with an authorization code.

  4. Your application

    exchanges the code for a token carrying the Core ID, and the person is signed in.

The bigger picture

An identity layer your users already carry, and your servers never hold.

Registration forms, password resets, email confirmation and manual document checks are each a system to build, secure and keep compliant, and each one is a copy of somebody's personal data that your organisation becomes responsible for. CorePass Connector replaces all four with one verified exchange that the person approves on their phone, leaving your application with an identifier and only the fields it asked for.

Verified data

KYC you request, and never collect.

Name the fields your compliance process actually needs — a date of birth, a document number, an address, an email address — and the person sees exactly that list on their phone before approving it. Nothing is uploaded, scanned or typed a second time: the values arrive at the callback you registered, each one carrying the pepper that lets you check it against the registry months later.

  • Ask only for the fields you need, and let the person approve them one screen at a time.
  • Re-check a value you already hold without asking the person for anything again.
POST /api/v1/kyc/qrcode
curl --request POST \
    --url https://auth-develop.corepassdev.eu/api/v1/kyc/qrcode \
    --header 'Content-Type: application/json' \
    --data '{
        "user":"ab72a31c718d343b45e558099ec503087f734433785d",
        "items":["DRIVER_LICENSE_DOCUMENT_NUMBER"],
        "callback":"https://your.example/kyc/callback",
        "statusCallback":"https://your.example/kyc/status",
        "expiration":1675946886
    }'

Retrieving KYC data

Verified businesses

Onboard a company the way you onboard a person.

A business has no phone of its own, so its members vote, and the data is released only when enough of them approve within a fixed twenty-four hour window. What reaches your endpoint is a signed attestation whose claims carry the values, which means a legal name, a registration number or a director's role cannot be read at all without verifying the signature first.

  • Ask a named business by wallet address, or mint a QR code and let a member choose which company answers.
  • Ask a business to sign your terms, and check the result against its own wallet contract.
POST /api/v1/kyb/data-requests
curl --request POST \
  --url https://api-develop.corepassdev.eu/api/v1/kyb/data-requests \
  --header 'Authorization: <api key>' \
  --header 'Idempotency-Key: 4b7f1c2e9a0d4f83' \
  --header 'Content-Type: application/json' \
  --data '{
    "businessWalletAddress": "cb12…",
    "fields": ["BUSINESS_LEGAL_NAME", "BUSINESS_REGISTRATION_NUMBER"],
    "optionalFields": ["BUSINESS_VAT_NUMBER"],
    "purpose": "Onboarding a business customer for wholesale orders",
    "reference": "your-own-id"
  }'

KYB attestations and signatures

Value of your data

The safest record is the one you never took.

Every credential an application stores is a credential it has to protect, rotate and eventually explain. CorePass Connector moves that responsibility back to the person it belongs to, and leaves your application holding an identifier, a consent trail and the handful of verified values it was granted.

No credential to lose

There is no password to hash, no reset link to send and no contact detail to confirm, because a sign-in is approved on a device the person already trusts rather than typed into a form.

Only the fields you asked for

A data request names the fields and nothing else. The person reads that list, approves it on their phone, and the values arrive at the endpoint you registered — with the ones they declined simply absent.

Checkable long after the fact

Every field arrives with the pepper that fingerprinted it, so you can ask the Core Blockchain registry later whether a value you still hold is valid, without ever going back to the person.

Enterprise ecosystem

Written for the compliance team as much as the engineer.

CorePass Connector lets an organisation digitise and automate identity verification while simplifying its KYC and AML obligations, maintaining GDPR compliance and adapting to the jurisdiction it operates in — because the personal data stays with the person, and what your systems hold is a record of what was granted and when. Business disclosure is prepaid in Swiss francs, priced per field, and refunded whenever a request is refused or expires.

Approval window
5–15 minutes for a person, a fixed 24 hours for a business.
Delivery
At least once, in order, retried on a schedule, and pullable from the API.
Authenticity
HMAC-SHA256 on every callback, RS256 attestations on every business release.
Attestation validity
168 hours, and the payload is retained for the same window.

Frequently asked questions

Want to know more? We have the answers.

The questions below are the ones that come up before an integration starts. Everything after that point is answered in the documentation, and anything neither covers is a short email away.

Contact us

Do the people using our application need a CorePass account?

Yes. A person installs the CorePass application, creates an account and then uses it to sign in anywhere CorePass Connector is integrated, which means the account they create for you is the same one they already use elsewhere. There is nothing for them to remember and nothing for you to reset.

What does our application actually store after a login?

The person's Core ID — their address in the Core ecosystem — and whatever your own application chooses to keep alongside it. There is no password to hash, no email address to confirm and no phone number to hold, because none of those are part of the flow.

How long does the integration really take?

The login is four steps and reads in about five minutes: register the client, put the QR snippet in your login page, handle the redirect back, and make your first call. Requesting verified identity data is a second, larger piece of work, because it adds a callback endpoint you have to register and verify.

Can we ask for only some identity fields?

You name the fields you want, one at a time, from the published vocabulary — a date of birth, a document number, an address, an email address — and the person sees exactly that list on their phone before approving it. Asking for less is both cheaper and far more likely to be approved.

What happens if the person has not verified the field we need?

Call the verified-items endpoint before you show anything: it answers with the items the person has verified and the items they have not. If a field your process depends on comes back unverified, tell the person to complete that verification in their CorePass application, because the transfer cannot be started without it.

How do we know a callback really came from CorePass?

Every KYC callback carries a Corepass-Signature header — an HMAC-SHA256 over the timestamp and the raw request body, keyed with the webhook secret registered for your domain. KYB deliveries use a separate header and a separate secret, and the values themselves arrive inside an RS256 attestation that you verify against a published key set.

How is KYB different from requesting data about a person?

A business has no phone to approve a request, so its members vote and the data is released only when enough of them agree, inside a fixed twenty-four hour window. The values arrive inside a signed attestation rather than beside one, which means there is no way to read a legal name or a registration number without verifying the signature first.

What does a KYB request cost?

Business field disclosure is prepaid in Swiss francs and priced per field, from registry basics at the lowest tier through documents and screening at the highest. A request reserves its quote when it is created and spends only the fields that were actually released, so a refusal or an expiry gives the money back. Signature requests are free.

What happens if our callback endpoint is down?

A KYC callback is retried on the intervals your deployment is configured with, and the data is held until the retries are exhausted. A KYB delivery is retried for roughly nine hours, and the release can also be pulled from the API while the payload is retained, so an endpoint that was down during the window is not a lost disclosure.

Get started

One integration, every verified identity.

Start with the login — it is four steps and about five minutes — and add verified data when your onboarding flow is ready for it. If you would rather talk it through first, the people who built the connector answer the mailbox.

Already using CorePass? The CorePass documentation covers the application your users install.