Skip to main content

Use AgeKey Authorization

The Use AgeKey authorization endpoint initiates the age verification flow for users who already have an AgeKey. Your application should redirect the user's browser to this endpoint with the appropriate parameters to start the verification process.

OIDC Specification

This endpoint implements the OpenID Connect Implicit Flow with id_token response type.

Authorization endpoint

curl -X GET "https://api.agekey.org/v1/oidc/use" \
-G \
-d "scope=openid" \
-d "response_type=id_token" \
-d "client_id=your-client-id" \
-d "redirect_uri=https://yourapp.com/agekey/callback" \
-d "state=abc123xyz789" \
-d "nonce=nonce456def" \
-d "claims=%7B%22age_thresholds%22%3A%5B13%2C18%5D%7D"

Parameters

ParameterTypeRequiredDescription
scopestringYesAlways set to openid, optionally can also set agekey.upgrade if upgrades are allowed
response_typestringYesAlways set to id_token
client_idstringYesYour AgeKey client ID
redirect_uristringYesWhere users return after verification
statestringYesClient-generated value for CSRF protection and maintaining application state
noncestringYesRandom value for replay protection
claimsstringYesURL-encoded JSON specifying age thresholds and other constraints
can_createstringNoWhen present and true, users see both "Use AgeKey" and "Create AgeKey". When omitted or not true, only "Use AgeKey" is shown.
languagestringNoOptional IETF BCP 47 language tag (for example en-US, pt-BR) to set the AgeKey UI language for this redirect. When omitted, the UI follows the visitor's browser language preferences. Applies to use and upgrade flows, which both use this authorization URL.

Claims parameter

The claims parameter must be a URL-encoded JSON object specifying which age thresholds to verify and filtering criteria:

FieldTypeRequiredDescription
age_thresholdsarrayYesArray of age thresholds to verify (for example [13, 18, 21])
allowed_methodsarrayNoArray of verification methods to accept. (for example ["id_doc_scan", "payment_card_network"]) All verification methods are considered when not provided.
verified_afterstringNoISO 8601 date/datetime - only accept verifications after this date
provenanceobjectNoFilter by verification provider origin (see provenance structure below)
overridesobjectNoMethod-specific filtering rules (see overrides structure below)

Provenance structure:

Provenance filtering allows you to control which verification providers are accepted based on their origin path. Each provider has a unique provenance path that identifies the verification technology used.

FieldTypeDescription
allowedarrayAllowed provenance patterns. Use * suffix for prefix matching (for example /veratad/* matches all Veratad providers)
deniedarrayDenied provenance patterns. Takes precedence over allowed. Use to exclude specific providers

Pattern matching:

  • Patterns must start with / and use lowercase letters, numbers, and underscores
  • Use /* suffix for prefix matching (for example /veratad/* matches /veratad/internal, /veratad/trinsic, and other paths under that prefix)
  • Exact paths match only that specific provider (for example /stripe only matches Stripe)
  • Maximum 10 patterns per array, each up to 100 characters

Example with provenance filtering:

{
"age_thresholds": [18],
"provenance": {
"allowed": ["/veratad/*", "/stripe", "/singpass"],
"denied": ["/veratad/internal"]
}
}

In this example:

  • All Veratad providers are allowed via the /veratad/* wildcard
  • Stripe and Singpass verifications are explicitly allowed
  • Veratad internal verifications are excluded (denied takes precedence over allowed)

Available provenances:

ProvenanceDescription
/connect_idConnect ID verification
/stripeStripe identity verification
/inicisInicis verification (Korea)
/singpassSingpass verification (Singapore)
/privyPrivy verification
/spruce_idSpruce ID verification
/verify_myVerifyMy verification
/privatelyPrivately verification
/veratad/internalVeratad internal verification
/veratad/trinsicVeratad via Trinsic
/veratad/craVeratad via CRA verification
/veratad/rocVeratad via ROC verification
/yotiYoti verification
/metaMeta verification
/friendly_id/amazonFriendly ID via Amazon
/paymenticoPaymentico verification

Overrides structure:

Each method key inside overrides accepts the following fields:

FieldTypeRequiredDescription
min_ageintegerNo*A single minimum age threshold for this method (0–150). For facial_age_estimation, exactly one of min_age or age_thresholds is required.
age_thresholdsarrayNo*Per-threshold overrides that map 1:1 by index to the root age_thresholds. Each entry is the minimum age (for this method) required to satisfy the corresponding root threshold. Length must equal root age_thresholds length.
verified_afterstringNoOverride verified_after for this specific method
attributesobjectNoMethod-specific attribute requirements

*For facial_age_estimation, one of min_age or age_thresholds must be provided.

Example with method and attribute filtering:

{
"age_thresholds": [13, 18],
"allowed_methods": ["id_doc_scan", "payment_card_network"],
"verified_after": "2024-01-01",
"overrides": {
"id_doc_scan": {
"attributes": {
"issuing_country": ["US", "GB"],
"face_match_performed": true
}
},
"payment_card_network": {
"attributes": {
"card_type": ["credit"]
}
}
}
}

Example with age_thresholds override for facial age estimation:

{
"age_thresholds": [13, 18],
"overrides": {
"facial_age_estimation": {
"age_thresholds": [16, 21]
}
}
}

In this example, root threshold 13 requires the facial age estimation to report at least 16, and root threshold 18 requires at least 21.

Example with min_age override for facial age estimation:

{
"age_thresholds": [18],
"overrides": {
"facial_age_estimation": {
"min_age": 21
}
}
}

Response

On success, users are redirected to your redirect_uri with an id_token, state, and potentially a code in the query string:

https://yourapp.com/agekey/callback?
id_token=eyJhbGc...long-jwt-string...&
state=abc123xyz789
User chose to create an AgeKey

When you sent can_create=true and the user was shown the use-or-create dialog and chose to create an AgeKey, they're redirected with create_requested=true and no id_token. Your app should send them to complete verification with another method (such as ID document scan). Once that verification succeeds, direct them to the Create AgeKey flow.

https://yourapp.com/agekey/callback?
state=abc123xyz789&
create_requested=true
Query parameterWhen presentDescription
id_tokenSuccessSigned JWT with age threshold results. Must be validated on your server before trusting the results.
stateAlwaysThe state value you sent; verify it for CSRF protection.
codeWith agekey_upgrade scopeReturned when using the agekey_upgrade scope; can be exchanged to upgrade an AgeKey with a new verification.
create_requestedWhen can_create=true was sentPresent and true when the user chose "Create AgeKey" in the use-or-create dialog. Send the user to complete verification with another method; after success, direct them to the Create AgeKey flow. No id_token is returned. Only returned if the request included can_create=true.
errorOn errorError code (for example, access_denied when the user clicks back or abandons the flow); handle appropriately.
note

The id_token contains age threshold results and must be validated on your server before trusting the results.

The code is returned when using the agekey.upgrade scope and can be used to upgrade an AgeKey with a new verification.

ID token claims

The decoded id_token JWT payload contains the following claims:

ClaimTypeDescription
substringSession ID. A unique identifier for this verification session. You should log this value for invalidation auditing (see note below).
issstringToken issuer. Always https://api.agekey.org/v1/oidc/use.
audarrayAudience. Contains your client_id.
iatnumberIssued-at timestamp (UNIX epoch seconds).
expnumberExpiration timestamp (UNIX epoch seconds). Token is valid for 10 minutes.
noncestringThe nonce value from your authorization request. Must match to prevent replay attacks.
age_thresholdsobjectMap of requested threshold to boolean result. For example { "13": true, "18": false }.
req_claims_hashstringBase64url-encoded SHA-256 hash of the claims JSON you sent, for request integrity verification.
c_hashstring(Only with agekey.upgrade scope) Code hash per OIDC spec §3.3.2.11.
Log the session ID

The sub claim is the session ID for this verification. Persist this value in your system alongside the verification outcome. If an age signal is later revoked or found to be fraudulent, this session ID is used for invalidation auditing to identify which verifications were affected. Without it, impacted sessions can't be traced back to your users.