Developer

Identification

Identify a user with Cleverbase, and read the attributes they consent to share. This is the API for the Identification service. The API is OpenID Connect, so if your stack already speaks OIDC, most of the work is configuration rather than code.

Cleverbase is the OpenID Provider; your application is the Relying Party. The user proves who they are in the Cleverbase app on their phone, and you receive an id_token with the claims they agreed to.

Hosts

EnvironmentHost
Pre-productionhttps://connect.acc.cleverbase.com
Productionhttps://connect.cleverbase.com

What the flow looks like

OpenID Provider (OP)Relying Party (RP)Web applicationToken endpointAuthorization endpointRedirection URI endpointWeb applicationUser agentWeb applicationToken endpointAuthorization endpointRedirection URI endpointWeb applicationUser agentRequest identity federationRedirect with authentication requestRequest authenticationLoad OP web applicationAuthenticate end-userObtain end-user consentRedirect with authorization codeExchange authorization code for access token and ID tokenProvide access token and ID tokenSecurely cache access token if subsequent use is planned,process identity claims, securely archive proofRedirect to RP web applicationUse RP web application with verified identity claims
  1. Your application redirects the user to GET /oauth2/authorize with the scopes for the claims you need.
  2. The user identifies themselves with Cleverbase and consents to the claims. What they see and how far they get is ours; you get no callbacks in between.
  3. Cleverbase redirects back to your redirection URI with an authorization code.
  4. Your server exchanges that code at POST /oauth2/token for an id_token and an access_token.
  5. Optionally you call GET /userinfo with the access token for the same claims outside the token.

The standard, and the parts of it that apply

The interface complies with OpenID Connect Core 1.0 incorporating errata set 1, which aligns with RFC 6749 (OAuth 2.0). The relevant OIDC sections are 1, 2, 3.1, 5, 8-10 and 13-17.

Two things are worth knowing before you design your screens: a user may consent to a subset of what you ask for unless you marked a claim essential, and a claim that cannot be shared is simply absent from the response rather than empty. Both are in Scopes and claims.