Overview
itsme® API is based on the Authorization Code Flow of OpenID Connect 1.0. The API can be used to verify your end-users’ identity and obtain some information about them. For the exact user data that can be requested, please see the Authorization Request parameters.
The diagram below describes the Confirmation process and how your systems should integrate with itsme® :
To get to this result please make sure you
- add itsme® button to your front-end page so the user can indicate he wishes to authenticate with itsme® : itsme® button specifications.
- create the Authorization Request to authenticate the User. This request will redirect the user to the itsme® app. itsme® will then authenticates the user by asking him
- to enter his phone number on the itsme® sign-in page
- authorize the release of some information to your application
- to provide his credentials (itsme® code, fingerprint or FaceID)
It is also in this Authorization Request that you will be able to request claims about the user and the Confirmation event. - collect the Authorization Code once the user has been authenticated and redirected by itsme® to your mobile or web application.
- exchange the Authorization Code for an ID token (e.g. identifying the user) and an Access Token.
- Obtain the additional claims by presenting the access token to the itsme® UserInfo Endpoint if the required claims are not returned in the ID token.
- Confirm the success of the operation and display a success message.
Onboarding
To make use of our services, you will need to contact our Customer Care team at onboarding@itsme-id.com. Based on your requirements, they will configure for you a new partner in our database. You will receive the clientID corresponding to this partner, that you will need to include in your Authorization Request.
Each partner can contain multiple “services”. Each service should correspond to one user flow at your side and can be of type Authentication, Identification or Confirmation. The service code will also be required in your Authorization Request.
For each service, you will have to provide one or a few “redirect_uri”, which are the landing page(s) where the end user will be sent after authenticating with itsme. Only the URIs whitelisted in a service will be allowed in your Authorization Request, so they have to be fully determined before you can use the service. This whitelisting works on an “exact match” basis, including the full (case sensitive) path and query string so please communicate the exact string you are planning to use in your Authorization Request.
Guides
Generate itsme® button
First, you will need to create a button to allow your users to authenticate with itsme®. Check the Button design guide before you start the integration.
Upon clicking this button, the user will be redirected to our Front-End. itsme® then take care of their authentication.
Securing the exchange of information
To protect the exchange of sensitive information and ensure the requested information gets issued to a legitimate application and not some other party, the OpenID Connect protocol uses JSON Web Token (JWT) which can be signed and/or encrypted. Among the methods described in OpenID specification, itsme® supports 2 authentication methods to secure communications between your backend and itsme®:
- "Private key JWT" is based on a public/private key pair (asymmetric encryption). It is therefore the most secure option
- "Client secret" is based on a shared Secret key (symmetric encryption). It can be easier to implement in some cases
Public-private key pair and JWKSet URI
This method uses a pair of keys (1 public, 1 private) to encrypt and decrypt senders’ and recipients’ sensitive data. It is also known as public-key cryptography or asymetric encryption.
You can retrieve the itsme® JWK Set from the URI mentioned as jwks_uri
in our itsme® Discovery document.
Secret key method
Secret key cryptography method uses the same secret key to encrypt and decrypt sensitive information. This approach is the inverse of public- and private-key encryption.
This method requires the exchange of a static secret to be held by both the sender and the data receiver. The secret value will be provided by itsme® when registering your project.
Key rotation procedure
for public-private key pair and JWKSet URI
itsme® backend has cache mechanism in place, which is sporadic (from 30min to 24h). During this time, we will keep on using old keys.
Rotating signing key:
- Add the new key to JWK set, with a new “kid”
- Start using the new key to sign JWTs
- When the flow is validated with the new key, remove the old one from the JWK set
Rotating encryption key:
- Replace the old key with the new one in JWK set, but still support old and new keys in decryption process
- Wait 24h (or wait for “max-age” amount of time, if specified)
- Decommission the old key completely
Changing the key could come along with changing the jwkset url. If that is the case, communicate new available jwkset url to onboarding@itsme-id.com. It is not be possible to be perfectly in sync, a few failed flows should be expected in the lapse of time between jwkset url update and the key update at the partner’s side. Smoother way would be:
- Copy the old jwkSet on the new URL
- the URL is communicated & registered by itsme®
- Rotate the keys in the jwkSet on the new URL as per rotating keys info above
for secret key method
Please, reach out to onboarding@itsme-id.com in case the secret key should be rotated.
PKCE-enhanced flow
Whatever the chosen authentication method, itsme® also supports an extra security extension named Proof of Key for Code Exchange (PKCE). This additionnal layer of security is intended to mitigate some Authorization Code interception attacks. For this mechanism to achieve its full potential, PKCE has to be made mandatory in your flow, which is an option we can enable for you (strongly recommended). Please ask our onboarding team to do so when registering your project.
PKCE implies choosing a random string, named code_verifier
, and then generating a SHA256 hash of that string, named code_challenge
. The code_challenge has to be sent along with the Authorization Request, while the code_verifier must be sent with the Token Request, allowing our backend to make sure both requests are issued by the same source.
code_challenge
can then be obtained via this kind of instructions:
var hash = code_verifier.createHash('sha256');
var code_challenge = base64url.encode(hash);
Signing, encrypting and decoding JWTs
Libraries implementing JWT and the JOSE specs JWS, JWE, JWK, and JWA are listed here. For testing purposes only, we could advise the use of https://mkjwk.org/ for JWK generation and https://mkjose.org/ for payload check => these are 2 open-source tools which will help you visualize JWK mechanisms, client assertion construct. Please DO NOT generate production private keys on any website. Rather opt for the relevant SDK library mentioned here.
Certificates and website security
itsme® requires https
connections to guarantee security. With the https
protocol, a web site operator obtains a certificate by applying to a certificate authority with a certificate signing request. The certificate request is an electronic document that contains the web site name, company information and the public key. The certificate provider signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site.
A certificate provider can opt to issue three types of certificates, each requiring its own degree of vetting rigor. In order of increasing rigor (and naturally, cost) they are: Domain Validation, Organization Validation and Extended Validation.
The Domain Validation certificate doesn’t provide sufficient identity guarantees to itsme. So, only the Organization Validation and Extended Validation certificates are supported. For example, using the Let’s Encrypt open certificate authority is not suffcient because it only provide standard Domain Validation certificates.
Handling responses
Whenever a partner is sending a request to the itsme OIDC endpoints he will get a response back. According to the OIDC protocol, and depending on the endpoint that was contacted, partners can get a
- response where some parameters are added to the query component of the redirection URI using the
application/x-www-form-urlencoded
format, or - response displayed directly on our itsme® sign-in page ;
- response using the
application/json
media type
Alongside the type of response an HTTP status code is sent that shows whether the request was successful or not. If it was not, you can tell by the code and the message in the response what went wrong, why it went wrong and whether there is something the partner can do about it.
A successful response
An HTTP status 200 OK
or 302 Found
is issued whenever your request was a success. You see this type of response in our examples like the one where we successfully retrieve the Token Response :
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"expires_in": 3600,
}
The error responses
Things will sometimes go wrong. So, OpenID Connect defines a number of rules regarding the format of errors returned from our endpoints.
Authorization Endpoint errors
If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid,… the Authorization Endpoint will inform you of the error our itsme® sign-in page.
If the User denies the access request or the User authentication fails, the Authorization Endpoint will inform you by adding the following parameters to the query component of the redirection URI using the application/x-www-form-urlencoded
format :
error REQUIRED | A single ASCII error code.
| ||||||||||||||||||||||||||||||||||
error_description OPTIONAL | Human-readable text providing additional information, used to assist the developer in understanding the error that occurred. | ||||||||||||||||||||||||||||||||||
state | The string value provided in the Authorization Request. You SHOULD validate that the value returned matches the one supplied. |
For example :
HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz
Token Endpoint errors
If the request fails the Token Endpoint responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters in the entity-body of the HTTP response using the application/json
media type :
error REQUIRED | A single ASCII error code.
| ||||||||
error_description OPTIONAL | Human-readable text providing additional information, used to assist the developer in understanding the error that occurred. |
For example :
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache
{
"error":"invalid_request"
}
UserInfo Endpoint errors
When a request fails, the UserInfo Endpoint responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and includes specific error codes in the response.
invalid_request | The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. |
invalid_token | The access token provided is expired, revoked, malformed, or invalid for other reasons. |
For example :
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Revocation Endpoint errors
If the request fails the Revoke Endpoint responds with an HTTP 400 (Bad Request) status code and includes the fllowing parameters in the entity-body of the HTTP response using the application/json
media type :
error REQUIRED | A single ASCII error code.
| ||||||||||
error_description OPTIONAL | Human-readable text providing additional information, used to assist the developer in understanding the error that occurred. | ||||||||||
state | The string value provided in the Authorization Request. You SHOULD validate that the value returned matches the one supplied. |
For example:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache
{
"error":"invalid_request"
}
WYSIWYS template
When building your Authorization Request, one of the below template MUST be specified in the claims
parameter.
Advanced Payment template
http://itsme.services/v2/claim/claim_approval_template_name | This identifies the template used. It MUST be set to "http://itsme.services/v2/claim/claim_approval_template_name":{ "essential": true, "value": "adv_payment" }. |
http://itsme.services/v2/claim/claim_approval_amount_key | A string holding an integer value inside. This MUST be set to "http://itsme.services/v2/claim/claim_approval_amount_key":{ "essential": true, "value": "Amount_as_a_string" }. |
http://itsme.services/v2/claim/claim_approval_currency_key | A string holding a valid currency code (e.g. “EUR”). This MUST be set to "http://itsme.services/v2/claim/claim_approval_currency_key":{ "essential": true, "value": "Currency_as_a_string" }. |
http://itsme.services/v2/claim/claim_approval_iban_key | A string holding a valid IBAN account number. This MUST be set to "http://itsme.services/v2/claim/claim_approval_iban_key":{ "essential": true, "value": "IBAN_as_a_string" }. |
Free Text template
http://itsme.services/v2/ claim/claim_approval_template_name | This identifies the template used. It MUST be set to "http://itsme.services/v2/claim/claim_approval_template_name":{ "essential": true, "value": "free_text" }. |
http://itsme.services/v2/ claim/claim_approval_text_key | A string holding any text to be displayed in the itsme® app. This MUST be set to"http://itsme.services/v2/claim/claim_approval_text_key":{ "essential": true, "value": "Text_as_a_string" }. |
We currently support the following HTML tags in the Free Text template: - < b > - < i > - < u > - < br >. Tags that are not rendered are ignored. The free text template can contain up to 7500 characters. We also only support the following character set: https://en.wikipedia.org/wiki/ISO/IEC_8859-15
Mapping the user
Mapping using sub
claim
To sign in successfully in your web desktop, mobile web or mobile application, a given user must be mapped to a user account in your database. By default, your application Server will use the subject identifier, or sub
claim, in the ID Token to identify and verify a user account. The sub
claim is a string that uniquely identifies a given user account. The benefit of using a sub
claim is that it will not change, even if other user attributes (email, phone number, etc) associated with that account are updated.
If no user record is storing the sub
claim value, then you should allow the user to associate his new or existing account to the sub
.
Benefit of sub
claim
The benefit of using a sub
claim is that it will not change, not even if other user attributes (email, phone number, etc.) associated with that account are updated.
Deleting and re-creating an itsme® account
In a limited number of cases (e.g. technical issue,…) a user could ask itsme® to ‘delete’ his account. As a result the specific account will be ‘archived’ (for compliancy reasons) and thus also the unique identifier(s) (e.g. “sub”).
If the same user would opt to re-create an itsme® afterwards, he will need to re-bind his itsme® account with your application server, in the same way as for the initial binding. After successful re-binding you will need to overwrite the initial reference with the new sub
claim value in your database.
User Data
itsme® is making a range of user data available for its partners. Those can be requested through the Authorization Request, individually as “claims” or as part of a broader “scope”. These claims can be split in 2 categories:
User Attributes
User attributes are saying something about the end user. They are part of the identity of a person and we retrieve them from an identity document (ID card, passport…). Examples: name, address, birthdate, etc.
Metadata
Metadata are saying something about the data we have for an end user. They are not directly related to a person, but rather to an information about this person. Examples are the validityTo, the verificationDate etc. Those metadata, if requested, will only return values relating to the user attributes that are also requested. The metadata will then return an object containing one value for each relevant user attribute.
Examples:
- The
verificationDate
is a metadata that has a value for most user attributes. So requesting theverificationDate
AND thebirthdate
AND thegiven_name
will return the following pattern forverificationDate
:
"http://itsme.services/v2/claim/verificationDate": {
"birthdate": "2023-06-01T13:04:26Z",
"given_name": "2023-06-01T13:04:26Z"
}
-
Requesting only the
verificationDate
will return nothing, as it only returns values for other requested attributes. -
The
validityTo
metadata only has a value forBEeidSn
andIDDocumentSN
(because other attributes don’t have an expiry date). SovalidityTo
will only return a value ifBEeidSn
and/orIDDocumentSN
is also requested. Even if other attributes are requested,validityTo
will not return a value for those other attributes.
API reference
itsme® Discovery Document
-
GET https://idp.[e2e/prd].itsme.services/v2/.well-known/openid-configuration
To simplify implementations and increase flexibility, OpenID Connect allows the use of a Discovery Document, a JSON document containing key-value pairs which provide details about itsme® configuration, such as the
Authorization, Token and userInfo Endpoints Supported claims ... -
GET https://oidc.[e2e/prd].itsme.services/clientsecret-oidc/csapi/v0.1/.well-known/openid-configuration
To simplify implementations and increase flexibility, OpenID Connect allows the use of a Discovery Document, a JSON document containing key-value pairs which provide details about itsme® configuration, such as the
Authorization, Token and userInfo Endpoints Supported claims ...
Authorization Request
-
GET https://idp.[e2e/prd].itsme.services/v2/authorization
Parameters
client_idREQUIREDIt identifies your application. This parameter value is generated during registration. response_typeREQUIREDThis defines the processing flow to be used when forming the response. Because itsme® supports the Authorization Code Flow, this value MUST be code
.scopeREQUIREDIt allows your application to express the desired scope of the access request. Each scope returns a set of user attributes. The scopes an application should request depend on which user attributes your application needs. Once the user authorizes the requested scopes, his details are returned in an ID Token and are also available through the UserInfo Endpoint.
All scope values must be space-separated.
The basic (and required) scopes areopenid
andservice
. Beyond that, your application can ask for additional standard scopes values which map to sets of related claims are:profile
email
address
phone
eid
serviceREQUIREDIt indicates the itsme® service your application intends to use, e.g. service:TEST_code
by replacing "TEST_code" with the service code generated during registration.openidREQUIREDIt indicates that your application intends to use the OpenID Connect protocol to verify a user's identity by returning a sub
claim which represents a unique identifier for the authenticated user.profileOPTIONALReturns claims that represent basic profile information, specifically family_name
,given_name
,name
,gender
,locale
,picture
andbirthdate
.
If requested, a value SHALL always be returned for the above claims except for thegiven_name
claim which MAY NOT be returned if the user doesn't have any first name(s).emailOPTIONALReturns the email
claim, which contains the user's email address, andemail_verified
, which is a boolean indicating whether the email address was verified by the user.
If requested, a value SHALL always be returned for theemail_verified
claim only ifemail
claim is filled with a value, whereas theemail
claim SHALL always be returned only if the user gave us an email address.addressOPTIONALReturns user's postal address, represented as JSON Object containing some or all of these members formatted
street_address
postal_code
locality
If requested, a value SHALL always be returned for users with a Belgian ID document, and SHALL NOT be returned for users with a Dutch ID documents.phoneOPTIONALReturns the phone_number
claim, which contains the user's phone number, andphone_number_verified
, which is a boolean indicating whether the phone number was verified by the user.
If requested, a value SHALL always be returned for the above claims.eidOPTIONALReturns the http://itsme.services/v2/claim/BENationalNumber
claim, which contains the unique identification number of natural persons who are registered in Belgium, andhttp://itsme.services/v2/claim/BEeidSn
, which is a string indicating the Belgian ID card number.
If requested, a value SHALL always be returned for the above claims.redirect_uriREQUIREDIt is the URL to which users are redirected once the authentication is complete.
The following restrictions apply to redirect URIs:The redirect URI MUST match the value preregistered during the registration. The redirect URI MUST begin with the scheme https
(refer to this section for more information).The redirect URI SHALL NOT be a custom URL. The fragment identifier introduced by a hash mark #
SHALL NOT be used.The redirect URI is case-sensitive. Its case MUST match the case of the URL path of your running application. For example, if your application includes as part of its path .../abc/response-oidc
, do not specify.../ABC/response-oidc
in the redirect URI. Because the web browser treats paths as case-sensitive, cookies associated with.../abc/response-oidc
MAY be excluded if redirected to the case-mismatched.../ABC/response-oidc
URL.If relevant (in case you have a mobile app) make sure that your redirect URIs support the Universal links and App links mechanism. Functionally, it will allow you to have only one single link that will either open your desktop web application, your mobile app or your mobile site on the User’s device. Universal links and App links are standard web links (http://mydomain.com) that point to both a web page and a piece of content inside an app. When a Universal Link is opened, the app OS checks to see if any installed app is registered for that domain. If so, the app is launched immediately without ever loading the web page. If not, the web URL is loaded into the webbrowser. stateStrongly RECOMMENDEDSpecifies any string value that your application uses to maintain state between your Authorization Request and the Authorization Server's response. You can use this parameter for several purposes, such as directing the user to the correct resource in your application and mitigating cross-site request forgery. nonceStrongly RECOMMENDEDA string value used to associate a session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. ui_localesOPTIONALIndicates the user's preferred languages for the itsme® sign-in page, represented as a space-separated list of language tag values, ordered by preference.
Possible values :fr
nl
de
en
displayOPTIONALSpecify how the itsme® sign-in page should be displayed to the user. Currently, only the page
value is supported but in the future we might support additional display modes liketouch
.acr_valuesOPTIONALIndicates the authentication method required to process the request, represented as a space-separated list of tag values, ordered by preference.
Possible values :http://itsme.services/v2/claim/acr_basic
http://itsme.services/v2/claim/acr_advanced
Note : if these two values are provided only the most constraining authentication method will be applied, e.g.http://itsme.services/v2/claim/acr_advanced
.
http://itsme.services/v2/
claim/acr_basicIt lets the user to choose either fingerprint usage (if device is compatible) or itsme® code. If the acr_values
parameter is not specified, this is the default authentication method.http://itsme.services/v2/
claim/acr_advancedIt forces the user to use his itsme® code. claimsOPTIONALAllows to request specific user's details ("claims"). You can choose to receive those claims either in the ID Token (from /token endpoint) or in the UserInfo object (from /userinfo endpoint).
It MUST be a JSON object containing an{"id_token":{...}}
member or a{"userinfo":{...}}
member respectively. This member will then contain all the desired claims - see example below.
Note: to avoid the need of a /userinfo request, itsme® recommends to retrieve the claims directly from the ID Token.
Supported claims are listed below. Please check this page for availability and format per country.
nameOPTIONALReturns user's full name in displayable form including all name parts, possibly including titles and suffixes. given_nameOPTIONALReturns user's given name(s) or first name(s). Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.
If requested, a value MAY NOT be returned if the user doesn't have any first name(s).family_nameOPTIONALReturns user's surname(s) or last name(s). Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters. birthdateOPTIONALReturn user's birthdate, represented as a string in YYYY-MM-DD date format. itsme® users are always 16 years old or more. http://itsme.services/v2/claim/birthdate_as_stringOPTIONALReturns user's birthdate in an unprocessed way, as mentioned on the ID document. itsme® users are always 16 years old or more. genderOPTIONALReturns user's gender. Possible values are : female
male
unknown
n/a
localeOPTIONALReturns user's itsme app language, represented as a string format. Possible values are : NL
FR
DE
EN
pictureOPTIONALReturns user's ID picture, represented as a URL string. This URL refers to an image file (for example, a JPEG, JPEG2000, or PNG image file). This image is the raw (unprocessed) image contained on the ID document.
Accessing this URL has to be done with your bearer token. Example:
GET /v2/picture HTTP/1.1
Host: idp.prd.itsme.services
Authorization: Bearer SlAV32hkKGhttp://itsme.services/v2/
claim/physical_person_photoOPTIONALReturns user's ID picture, represented as a JSON Object containing these members: format
: the MIME typevalue
: the base64 encoded image.
This picture is read from the ID document but converted to always return a 200x140 px, 24 BPP JPEG image.emailOPTIONALReturns user's email address. email_verifiedOPTIONALReturns true
if the user's e-mail address is verified; otherwisefalse
.
Note : currently, itsme® always returnsfalse
for this claim because the email verification feature is not yet implemented in our systems.
If requested, a value SHALL NOT be returned if theemail
claim is not filled with a value.phone_numberOPTIONALReturns user's phone number, represented as a string format. For example : [+][country code] [subscriber number including area code]
.phone_number_verifiedOPTIONALReturns true
if the user's phone number is verified; otherwisefalse
.
Note: currently, all phone numbers are verified so this claims always returnstrue
.addressOPTIONALReturns user's postal address, represented as JSON Object containing some or all of these members: formatted
street_address
postal_code
locality
.http://itsme.services/v2/
claim/claim_citizenshipOPTIONALReturns user's nationality. The format is directly depending on the underlying ID document: for Belgian ID documents this is represented as a string, and for Dutch ID documents this is represented in the ISO 3166-1 alpha-3 format. http://itsme.services/v2/
claim/claim_citizenship_as_isoOPTIONALReturns user's nationality. The format is always ISO 3166-1 alpha-3.
Please be aware that this claim is computed by itsme® for users with a Belgian ID document on a best effort basis. For the original value as stored on the ID document, see http://itsme.services/v2/claim/claim_citizenship above. Therefore, a value MAY NOT be returned for users with a Belgian ID document.http://itsme.services/v2/
claim/place_of_birthOPTIONALReturns user's place of birth, represented as a JSON Object containing some or all of these members formatted
city
country
.http://itsme.services/v2/
claim/BEeidSnOPTIONALReturns user's Belgian ID document number, represented as a string with 12 digits in the form xxx-xxxxxxx-yy. (the check-number yy is the remainder of the division of xxxxxxxxxx by 97) for Belgian citizens, or starting with a letter and nine digits in the form B xxxxxxx xx for EU/EEA/Swiss citizens. This claim is made redundant by the IDDocumentSN
claim below which we advise to use instead.http://itsme.services/v2/
claim/claim_deviceOPTIONALReturns user's phone information, represented as a JSON Object containing some or all of these members os
appName
appRelease
deviceLabel
debugEnabled
deviceID
osRelease
manufacturer
deviceLockLevel
rooted
deviceModel
.http://itsme.services/v2/
claim/transaction_infoOPTIONALReturns information about the itsme® transaction, represented as a JSON Object containing some or all of these members securityLevel
bindLevel
appRelease
.http://itsme.services/v2/
claim/BENationalNumberOPTIONALReturns user's Belgian unique identification number, represented as a string with 11 digits in the form YY.MM.DD-xxx.cd where YY.MM.DD is the birthdate of the person, xxx a sequential number (odd for males and even for females) and cd a check-digit. Some exceptions could apply. http://itsme.services/v2/
claim/validityFromOPTIONALReturns user's Belgian ID document issuance date, represented as a string in YYYY-MM-DDThh:mm:ss.nnnZ date format specified by ISO 8601. Can only be returned in combination with claim http://itsme.services/v2/claim/BEeidSn. http://itsme.services/v2/
claim/validityToOPTIONALReturns user's Belgian ID card expiry date, represented as a string in YYYY-MM-DDThh:mm:ss.nnnZ date format specified by ISO 8601. Can only be returned in combination with claim http://itsme.services/v2/claim/BEeidSn. http://itsme.services/v2/
claim/verificationDateOPTIONALReturns the date when the user's document was read for the last time, represented as a string in YYYY-MM-DDThh:mm:ss date format specified by ISO 8601. http://itsme.services/v2/
claim/IDDocumentSNOPTIONALReturns the Dutch ID card/passport number, represented as a string composed of letters at positions 1 and 2 ; letters or digits from positions 3-8: ; and a digit at position 9. The letter ‘O’ is not used in the document numbers. The digit ‘0’ (zero) MAY be used. http://itsme.services/v2/
claim/IDDocumentTypeOPTIONALReturns the ID document type. This is a 1 or 2 characters code defined by the ICAO. Identity cards have a code with first letter I while passports have a code starting with P. http://itsme.services/v2/
claim/issuance_localityOPTIONALReturns the locality that issued the ID document used to create the itsme® account. subOPTIONALAllows the user to bypass the itsme® identification page if he is already logged into your application, by using the user's unique identifier key as value (aka. the user's sub
value returned in the ID Token response).
The sub must be passed as a JSON object like:"sub":{"value":"123456abcdefg"}
request_uriREQUIRED if no "request"A URL using the https scheme referencing a resource containing a JWT whose claims are the request parameters. The request_uri
parameter is used to secure parameters in the Authorization Request from tainting or inspection when sending the request to the itsme® Authorization Endpoint.
If therequest_uri
parameter is used, the JWT MUST be signed and MUST contain the claimsiss
(issuer) andaud
(audience) as members. Theiss
value SHOULD be yourclient_id
. Theaud
value SHOULD be set tohttps://idp.[e2e/prd].itsme.services/v2
. The JWT MUST also be encrypted and more precisely: it MUST be signed then encrypted, with the result being a Nested JWT (refer to this page for more information).
The following restrictions apply to request URIs:The request URI MUST be preregistered during the registration. The request URI MUST contain the TCP port number 443
. Example : https://test.istme.be:443/p/testThe request URI MUST begin with the scheme https
(refer to this section for more information). The usage of localhost request URIs that are not permitted.The request URI JWT MUST be publicly accessible. requestREQUIRED if no "request_uri"It represents the request as a JWT whose Claims are the request parameters. The request
parameter is used to secure parameters in the Authorization Request from tainting or inspection when sending the request to the itsme® Authorization Endpoint.
If therequest
parameter is used, the JWT MUST be signed and MUST contain the claimsiss
(issuer) andaud
(audience) as members. Theiss
value SHOULD be yourclient_id
. Theaud
value SHOULD be set tohttps://idp.[e2e/prd].itsme.services/v2
. The JWT MUST also be encrypted and more precisely: it MUST be signed then encrypted, with the result being a Nested JWT (refer to this page for more information).code_challengeOPTIONALA challenge derived from the code verifier by applying a S256 hash. This parameter is REQUIRED if you requested PKCE to be enforced. code_challenge_methodOPTIONALCode verifier transformation method.
It MUST be set toS256
.Response
302
application/x-www-form-urlencoded
codeAn intermediate opaque credential of 36 characters used to retrieve the ID Token and Access Token.
Note : the code has a lifetime of 3 minutes.stateThe string value provided in the Authorization Request. You SHOULD validate that the value returned matches the one supplied. -
GET https://oidc.[e2e/prd].itsme.services/clientsecret-oidc/csapi/v0.1/connect/authorize
Parameters
client_idREQUIREDIt identifies your application. This parameter value is generated during registration. response_typeREQUIREDThis defines the processing flow to be used when forming the response. Because itsme® supports the Authorization Code Flow, this value MUST be code
.scopeREQUIREDIt allows your application to express the desired scope of the access request. Each scope returns a set of user attributes. The scopes an application should request depend on which user attributes your application needs. Once the user authorizes the requested scopes, his details are returned in an ID Token and are also available through the UserInfo Endpoint.
All scope values must be space-separated.
The basic (and required) scopes areopenid
andservice
. Beyond that, your application can ask for additional standard scopes values which map to sets of related claims are:profile
email
address
phone
eid
serviceREQUIREDIt indicates the itsme® service your application intends to use, e.g. service:TEST_code
by replacing "TEST_code" with the service code generated during registration.openidREQUIREDIt indicates that your application intends to use the OpenID Connect protocol to verify a user's identity by returning a sub
claim which represents a unique identifier for the authenticated user.profileOPTIONALReturns claims that represent basic profile information, specifically family_name
,given_name
,name
,gender
,locale
,picture
andbirthdate
.
If requested, a value SHALL always be returned for the above claims except for thegiven_name
claim which MAY NOT be returned if the user doesn't have any first name(s).emailOPTIONALReturns the email
claim, which contains the user's email address, andemail_verified
, which is a boolean indicating whether the email address was verified by the user.
If requested, a value SHALL always be returned for theemail_verified
claim only ifemail
claim is filled with a value, whereas theemail
claim SHALL always be returned only if the user gave us an email address.addressOPTIONALReturns user's postal address, represented as JSON Object containing some or all of these members formatted
street_address
postal_code
locality
If requested, a value SHALL always be returned for users with a Belgian ID document, and SHALL NOT be returned for users with a Dutch ID documents.phoneOPTIONALReturns the phone_number
claim, which contains the user's phone number, andphone_number_verified
, which is a boolean indicating whether the phone number was verified by the user.
If requested, a value SHALL always be returned for the above claims.eidOPTIONALReturns the http://itsme.services/v2/claim/BENationalNumber
claim, which contains the unique identification number of natural persons who are registered in Belgium, andhttp://itsme.services/v2/claim/BEeidSn
, which is a string indicating the Belgian ID card number.
If requested, a value SHALL always be returned for the above claims.redirect_uriREQUIREDIt is the URL to which users are redirected once the authentication is complete.
The following restrictions apply to redirect URIs:The redirect URI MUST match the value preregistered during the registration. The redirect URI MUST begin with the scheme https
(refer to this section for more information). There is an exception for localhost redirect URIs that are only permitted for development purposes, it’s not for use in production.The redirect URI SHALL NOT be a custom URL. The fragment identifier introduced by a hash mark #
SHALL NOT be used.The redirect URI is case-sensitive. Its case MUST match the case of the URL path of your running application. For example, if your application includes as part of its path .../abc/response-oidc
, do not specify.../ABC/response-oidc
in the redirect URI. Because the web browser treats paths as case-sensitive, cookies associated with.../abc/response-oidc
MAY be excluded if redirected to the case-mismatched.../ABC/response-oidc
URL.If relevant (in case you have a mobile app) make sure that your redirect URIs support the Universal links and App links mechanism. Functionally, it will allow you to have only one single link that will either open your desktop web application, your mobile app or your mobile site on the User’s device. Universal links and App links are standard web links (http://mydomain.com) that point to both a web page and a piece of content inside an app. When a Universal Link is opened, the app OS checks to see if any installed app is registered for that domain. If so, the app is launched immediately without ever loading the web page. If not, the web URL is loaded into the webbrowser. stateStrongly RECOMMENDEDSpecifies any string value that your application uses to maintain state between your Authorization Request and the Authorization Server's response. You can use this parameter for several purposes, such as directing the user to the correct resource in your application and mitigating cross-site request forgery. nonceStrongly RECOMMENDEDA string value used to associate a session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authorization Request to the ID Token. ui_localesOPTIONALIndicates the user's preferred languages for the itsme® sign-in page, represented as a space-separated list of language tag values, ordered by preference.
Possible values :fr
nl
de
en
displayOPTIONALSpecify how the itsme® sign-in page should be displayed to the user. If set to touch
, it SHOULD displays the itsme® sign-in page with a device that leverages a touch interface. If set topage
, the itsme® sign-in UI SHOULD be consistent with a full page view of the User-Agent. If thedisplay
parameter is not specified, this is the default display mode.acr_valuesOPTIONALIndicates the authentication method required to process the request, represented as a space-separated list of tag values, ordered by preference.
Possible values :http://itsme.services/v2/claim/acr_basic
http://itsme.services/v2/claim/acr_advanced
Note : if these two values are provided only the most constraining authentication method will be applied, e.g.http://itsme.services/v2/claim/acr_advanced
.
http://itsme.services/v2/
claim/acr_basicIt lets the user to choose either fingerprint usage (if device is compatible) or itsme® code. If the acr_values
parameter is not specified, this is the default authentication method.http://itsme.services/v2/
claim/acr_advancedIt forces the user to use his itsme® code. claimsOPTIONALAllows to request specific user's details ("claims"). You can choose to receive those claims either in the ID Token (from /token endpoint) or in the UserInfo object (from /userinfo endpoint).
It MUST be a JSON object containing an{"id_token":{...}}
member or a{"userinfo":{...}}
member respectively. This member will then contain all the desired claims together with indication whether the claim is voluntary (returned if available) or essential (flow will stop if unavailable) - see example below.
Note: to avoid the need of a /userinfo request, itsme® recommends to retrieve the claims directly from the ID Token.
Supported claims are listed below.
nameOPTIONALReturns user's full name in displayable form including all name parts, possibly including titles and suffixes.
If requested, a value SHALL always be returned for this claim.given_nameOPTIONALReturns user's given name(s) or first name(s). Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.
If requested, a value MAY NOT be returned if the user doesn't have any first name(s).family_nameOPTIONALReturns user's surname(s) or last name(s). Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.
If requested, a value SHALL always be returned for this claim.birthdateOPTIONALReturn user's birthdate, represented as a string in YYYY-MM-DD date format. itsme® users are always 16 years old or more.
BE: If requested, a value MAY NOT be returned for users with a Belgian ID document. It forms a pair with thebirthdate_as_string
claim: at least one of the 2 SHALL return a value.
NL: A value SHALL always be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.http://itsme.services/v2/claim/birthdate_as_stringOPTIONALReturns user's birthdate in an unprocessed way, as mentioned on the ID document. itsme® users are always 16 years old or more.
BE: If requested, a value MAY NOT be returned for users with a Belgian ID document. It forms a pair with thebirthdate
claim: at least one of the 2 SHALL return a value.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.genderOPTIONALReturns user's gender. Possible values are : female
male
unknown
n/a
BE: A value SHALL always be returned for users with a Belgian ID document. Belgian accounts can only befemale
ormale
NL: A value MAY NOT be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.localeOPTIONALReturns user's mobile phone language, represented as a string format. Possible values are : NL
FR
DE
EN
If requested, a value MAY NOT be returned for this claim.pictureOPTIONALReturns user's ID picture, represented as a URL string. This URL refers to an image file (for example, a JPEG, JPEG2000, or PNG image file). This image is the raw (unprocessed) image contained on the ID document.
BE: A value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL always be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.
Accessing this URL has to be done with your bearer token. Example:
GET /v2/picture HTTP/1.1
Host: idp.prd.itsme.services
Authorization: Bearer SlAV32hkKGhttp://itsme.services/v2/
claim/physical_person_photoOPTIONALReturns user's ID picture, represented as a JSON Object containing these members: format
: the MIME typevalue
: the base64 encoded image.
This picture is read from the ID document but converted to always return a 200x140 px, 24 BPP JPEG image.
BE: A value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL always be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.emailOPTIONALReturns user's email address.
If requested, a value MAY NOT be returned if the user doesn't gave us an email address.email_verifiedOPTIONALReturns true
if the user's e-mail address is verified; otherwisefalse
.
Note : currently, itsme® always returnsfalse
for this claim because the email verification feature is not yet implemented in our systems.
If requested, a value SHALL NOT be returned if theemail
claim is not filled with a value.phone_numberOPTIONALReturns user's phone number, represented as a string format. For example : [+][country code] [subscriber number including area code]
.
If requested, a value SHALL always be returned for this claim.phone_number_verifiedOPTIONALReturns true
if the user's phone number is verified; otherwisefalse
.
If requested, a value SHALL always be returned for this claim.
Note: currently, all phone numbers are verified so this claims always returnstrue
.addressOPTIONALReturns user's postal address, represented as JSON Object containing some or all of these members: formatted
street_address
postal_code
locality
.
BE: A value SHALL always be returned for users with a Belgian ID document.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/claim_citizenshipOPTIONALReturns user's nationality. The format is directly depending on the underlying ID document: for Belgian ID documents this is represented as a string, and for Dutch ID documents this is represented in the ISO 3166-1 alpha-3 format.
If requested, a value SHALL always be returned for this claim.http://itsme.services/v2/
claim/claim_citizenship_as_isoOPTIONALReturns user's nationality. The format is always ISO 3166-1 alpha-3.
BE: Please be aware that this claim is computed by itsme® for users with a Belgian ID document on a best effort basis. For the original value as stored on the ID document, see http://itsme.services/v2/claim/claim_citizenship above. Therefore, a value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL always be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/place_of_birthOPTIONALReturns user's place of birth, represented as a JSON Object containing some or all of these members formatted
city
country
.
BE: A value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/BEeidSnOPTIONALReturns user's Belgian ID document number, represented as a string with 12 digits in the form xxx-xxxxxxx-yy. (the check-number yy is the remainder of the division of xxxxxxxxxx by 97) for Belgian citizens, or starting with a letter and nine digits in the form B xxxxxxx xx for EU/EEA/Swiss citizens. This claim is made redundant by the IDDocumentSN
claim below which we advise to use instead.
BE: A value SHALL always be returned for users with a Belgian ID document.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/claim_deviceOPTIONALReturns user's phone information, represented as a JSON Object containing some or all of these members os
appName
appRelease
deviceLabel
debugEnabled
deviceID
osRelease
manufacturer
deviceLockLevel
smsEnabled
rooted
msisdn
deviceModel
sdkRelease
.
If requested, a value MAY NOT be returned for this claim.http://itsme.services/v2/
claim/transaction_infoOPTIONALReturns information about the itsme® transaction, represented as a JSON Object containing some or all of these members securityLevel
bindLevel
appRelease
.
If requested, a value MAY NOT be returned for this claim.http://itsme.services/v2/
claim/BENationalNumberOPTIONALReturns user's Belgian unique identification number, represented as a string with 11 digits in the form YY.MM.DD-xxx.cd where YY.MM.DD is the birthdate of the person, xxx a sequential number (odd for males and even for females) and cd a check-digit. Some exceptions could apply.
BE: A value SHALL always be returned for users with a Belgian ID document.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/validityFromOPTIONALReturns user's Belgian ID document issuance date, represented as a string in YYYY-MM-DDThh:mm:ss.nnnZ date format specified by ISO 8601. Can only be returned in combination with claim http://itsme.services/v2/claim/BEeidSn.
BE: A value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL NOT be returned for users with a Dutch ID document.
LU: A value SHALL NOT be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/validityToOPTIONALReturns user's Belgian ID card expiry date, represented as a string in YYYY-MM-DDThh:mm:ss.nnnZ date format specified by ISO 8601. Can only be returned in combination with claim http://itsme.services/v2/claim/BEeidSn.
If requested, a value MAY NOT be returned for users with a Belgian ID document, and MAY NOT be returned for users with a Dutch ID document.http://itsme.services/v2/
claim/verificationDateOPTIONALReturns the date when the user's document was read for the last time, represented as a string in YYYY-MM-DDThh:mm:ss date format specified by ISO 8601.
BE: A value MAY NOT be returned for users with a Belgian ID document.
NL: A value SHALL always be returned for users with a Dutch ID document.
LU: A value SHALL always be returned for users with a Luxembourgish ID document.http://itsme.services/v2/
claim/IDDocumentSNOPTIONALReturns the Dutch or Luxembourgish ID card/passport number, represented as a string. (NL doc SN is composed of letters at positions 1 and 2 ; letters or digits from positions 3-8: ; and a digit at position 9. The letter ‘O’ is not used in the NL document numbers. The digit ‘0’ (zero) MAY be used.)
If requested, a value SHALL always be returned for this claim.http://itsme.services/v2/
claim/IDDocumentTypeOPTIONALReturns the ID document type. This is a 1 or 2 characters code defined by the ICAO. Identity cards have a code with first letter I while passports have a code starting with P.
If requested, a value SHALL always be returned for this claim.http://itsme.services/v2/
claim/IDIssuingCountryOPTIONALReturns the 3-letters iso code of the country that issued the identity document.
If requested, a value SHALL always be returned for this claim.http://itsme.services/v2/
claim/issuance_localityOPTIONALReturns the locality that issued the ID document used to create the itsme® account.
If requested, a value MAY NOT be returned for this claim.subOPTIONALAllows the user to bypass the itsme® identification page if already logged into your application, by using the user's unique identifier key as value (aka. the user's </tr>sub
value returned in a previous Token response). Please, use the following syntax: "sub":{"value":"YOUR_SUB"}request_uriREQUIRED if no "request"A URL using the https scheme referencing a resource containing a JWT whose claims are the request parameters. The request_uri
parameter is used to secure parameters in the Authorization Request from tainting or inspection when sending the request to the itsme® Authorization Endpoint.
If therequest_uri
parameter is used, the JWT MUST be signed and MUST contain the claimsiss
(issuer) andaud
(audience) as members. Theiss
value SHOULD be yourclient_id
. Theaud
value SHOULD be set tohttps://idp.[e2e/prd].itsme.services/v2/authorization
. The JWT MAY also be encrypted. If both signing and encryption are performed, it MUST be signed then encrypted, with the result being a Nested JWT (refer to this page for more information).
The following restrictions apply to request URIs:The request URI MUST be preregistered during the registration. The request URI MAY contain any TCP port number. Example : https://test.istme.be:443/p/test The request URI MUST begin with the scheme https
(refer to this section for more information). The usage of localhost request URIs that are not permitted.The request URI JWT MUST be publicly accessible. requestREQUIRED if no "request_uri"It represents the request as a JWT whose Claims are the request parameters. The request
parameter is used to secure parameters in the Authorization Request from tainting or inspection when sending the request to the itsme® Authorization Endpoint.
If therequest
parameter is used, the JWT MUST be signed and MUST contain the claimsiss
(issuer) andaud
(audience) as members. Theiss
value SHOULD be yourclient_id
. Theaud
value SHOULD be set tohttps://idp.[e2e/prd].itsme.services/v2/authorization
. The JWT MAY also be encrypted. If both signing and encryption are performed, it MUST be signed then encrypted, with the result being a Nested JWT (refer to this page for more information).code_challengeOPTIONALA challenge derived from the code verifier by applying a S256 hash. This parameter is REQUIRED if you requested PKCE to be enforced. code_challenge_methodOPTIONALCode verifier transformation method.
It MUST be set toS256
.Response
302
application/x-www-form-urlencoded
codeAn intermediate opaque credential of 36 characters used to retrieve the ID Token and Access Token.
Note : the code has a lifetime of 3 minutes.stateThe string value provided in the Authorization Request. You SHOULD validate that the value returned matches the one supplied.
Example
-
Request
GET /v2/authorization HTTP/1.1 Host: server.example.com response_type=code &client_id=OIDC_TEST1 &redirect_uri=https://client.example.org/cb &scope=openid+service:EXAMPLE+profile+phone+email+address+eid &state=anystate &nonce=anonce &prompt=login+consent &max_age=1 &request_uri=https://client.example.org/RequestObject.json
Response
HTTP/1.1 302 Found Location: https://client.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA &state=anystate
-
Request
GET /authorize HTTP/1.1 Host: server.example.com response_type=code &client_id=OIDC_TEST1 &redirect_uri=https://client.example.org/cb &scope=openid+service:EXAMPLE+profile+phone+email+address+eid &state=anystate &nonce=anonce &prompt=login+consent &max_age=1 &request_uri=https://client.example.org/RequestObject.json
Response
HTTP/1.1 302 Found Location: https://client.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA &state=anystate
Token Request
-
POST https://idp.[e2e/prd].itsme.services/v2/token
To assert the identity of the user, the
code
received previously needs to be exchanged for an ID token and access token. During this step, your application has to authenticate itself to our server using the public- and private-key pair method.Parameters
grant_typeREQUIREDSet this to authorization_code
to tell the Token Endpoint that your application wants to exchange an authorization code for an ID token and access token.codeREQUIREDThe intermediate opaque credential received in the Authorization Response. redirect_uriREQUIREDIt is the URL to which users are redirected once the authentication is complete. It MUST match the value used in the Authorization Request. code_verifierOPTIONALHigh-entropy cryptographic random string using the unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", with a minimum length of 43 characters and a maximum length of 128 characters. This parameter is REQUIRED if you required PKCE to be enforced. client_assertion_typeREQUIREDSpecifies the type of assertion. Set this to urn:ietf:params:oauth:client-assertion-type:jwt-bearer
.client_assertionREQUIREDIs a set of identity and security information, in the form of a JWT, used as an authentication method. To ensures that the request to get the id token and access token is made only from your application, and not from a potential attacker that may have intercepted the authorization code, the JWT MUST be signed, and MAY also be encrypted. If both signing and encryption are performed, it MUST be signed then encrypted, with the result being a Nested JWT (refer to this page for more information).
The JWT contains the following claims.issREQUIREDThe issuer of the token. This value MUST be the same as the client_id
.subREQUIREDThe subject of the token. This value MUST be the same as the client_id
.audREQUIREDThe full URL of the resource you're using the JWT to authenticate to. Set this to https://idp.[e2e/prd].itsme.services/v2/token
.jtiREQUIREDAn unique identifier for the token, containing maximum 255 characters. expREQUIREDThe expiration time of the token in seconds since January 1, 1970 UTC. iatOPTIONALThe time at which the JWT was issued. Response
200
application/json
access_tokenAllows an application to retrieve consented user information from the UserInfo Endpoint. token_typeProvides your application with the information required to successfully utilize the access token. Returned value is Bearer
..id_tokenA security token that contains information about the authentication of an user, and potentially other requested claim data's. The id_token
value is represented as a signed and encrypted JWT. So, before being able to use the ID Token claims you will have to decrypt and verify the signature (refer to this page for more information). -
POST https://oidc.[e2e/prd].itsme.services/clientsecret-oidc/csapi/v0.1/connect/token
To assert the identity of the user, the
code
received previously needs to be exchanged for an ID token and access token. During this step, your application has to authenticate itself to our server using the secret key method.Parameters
grant_typeREQUIREDSet this to authorization_code
to tell the Token Endpoint that your application wants to exchange an authorization code for an ID koken and access token.client_idREQUIREDIt identifies your application. This parameter value is generated during registration. codeREQUIREDThe intermediate opaque credential received in the Authorization Response. redirect_uriREQUIREDIt is the URL to which users are redirected once the authentication is complete. It MUST match the value used in the Authorization Request. client_secretREQUIREDContains the a key you reveiced when registering your application. This ensures that the request to get the id token and access token is made only from your application, and not from a potential attacker that may have intercepted the authorization code. code_verifierOPTIONALHigh-entropy cryptographic random string using the unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", with a minimum length of 43 characters and a maximum length of 128 characters. This parameter is REQUIRED if you required PKCE to be enforced. Response
200
application/json
access_tokenAllows an application to retrieve consented user information from the UserInfo Endpoint. token_typeProvides your application with the information required to successfully utilize the access token. Returned value is Bearer
.id_tokenA security token that contains information about the authentication of an user, and potentially other requested claim data's. The id_token
value is represented as a signed and encrypted JWT. So, before being able to use the ID Token claims you will have to decrypt and verify the signature (refer to this page for more information).
Example
-
Request
POST /token HTTP/1.1 Host: openid.c2id.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer &client_assertion=PHNhbWxwOl ... ZT
Response
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" "access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600, }
Example of a decrypted id_token:
{ "sub": "6g2k9rgglem2dttw5d51ulkxpv24phwatiu6", "aud": "WXw9DMqkEv", "birthdate": "1974-10-23", "gender": "male", "name": "John Ronald R Tolkien", "iss": "https://idp.prd.itsme.services/v2", "nonce": "nonce", "exp": 1699538407, "iat": 1699538107 }
-
Request
POST /token HTTP/1.1 Host: openid.c2id.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &client_id=s6BhdRkqt3 &client_secret=PHNhbWxwOl ... ZT
Response
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "id_token": "eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..UPzPZWb Da_ZvysMK.7ZXAFd24uTT35_gzrdYeuLBPrPR3Gc8VdB7L7MgZWgS4hiP 72URWNDPbOMLYw4xHx2CVKPGp9K0L05UeSMDcB39n_anV5nZ3BbkNsufx RiANOfoxx2W5jsb8Fj5W8F862wRWmClxTOosszauVhD6ZbhpJM0k9Iw7T CmwlmK3WMg9aE-gSNlvsjgrfB5QFmgYH2PWF1YdWZ1gCdCw3rz1XvxHPV yR9PfSy7SFFEoZos-2Y_rlO4R5_Oel3xy0YA_OucJVnV2x6oblxQ4TBXB 8YMCYyk3m7aS_S_oEs-2yAGCbQgwKU9jwqytF8Yw5X_rZmcbTpdvAF5qu ozfnoiW2ijHxr6xlH_8cibSIjhKOHEPCBTc8AeAb9nHLGrx0H1q02o7nz U-TwxUayrHXLBKd72l6aD8RxwCziATzjVWnvVVR7BmvOAV8L8IY_DTGgn iH2NlHL6_2KVtuB8czkDjEToE-JUfuzoedja9PTzRp6paO3ZpXSQcLl6a 6qBe526hMNEiK9VPRWPOJ8xIqwpg3mSeMjdkvSS6A9xJVH_xEy9jzts1n k2ge-YGrZZiQt8Do7NCd-ic7_HU8timZ_mfPFc8NDYgr0WtPefDQlC6en 8sUcMjuhuZOx_A3cQ7Mvoq662meUbkN64z50oBoh8Drora69I85zXQwes sR9f4z0th2-XDDrPxPop6yuJx8vMmRQNhN55qvwxgFMTEJyvDNAVfBA9s FZlj4hubY3wtYP5nLADjIFLresbrsu6iFQaE7v01FUMMDXcvBi_hw-M9s 0nBuWsQa2rZRcrVJOK9HVXUxXdUfTNL4MrrG5UzT7gdtcpesXeFVLSJtq 7HEGlHi3xaefgo4P5GN562CGVUl41BSmoBJT9oS5YJWKJOEOfpcAhYLKM 5iyMbgOxVz1Fz7z6Pfcd-PRcRlSQlHBXCdhP01AmRw-H_bdoKFIM1D33B 3AmmEKD6XRe8XM79F_gwySJ3AIWUzVLpJxe1lUphzIgy5O-VleJWyKl3D nAkCQwvqV-P-MrjirZckzlDjjfyOlEA_KNAK-PwCvZ5Yh_Wv8f-8LXUWJ ewfOCZmOM5pSKYXl-oZ.hfcIWiYPCtQMheNN8FB0Ww" "access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600, }
Example of a decrypted id_token:
{ "sub": "6g2k9rgglem2dttw5d51ulkxpv24phwatiu6", "aud": "WXw9DMqkEv", "birthdate": "1974-10-23", "gender": "male", "name": "John Ronald R Tolkien", "iss": "https://oidc.prd.itsme.services/clientsecret-oidc/csapi/v0.1", "nonce": "5468798645321", "nbf": 1699538107, "exp": 1699538407, "iat": 1699538107 }
UserInfo Request
-
GET https://idp.[e2e/prd].itsme.services/v2/userinfo
The UserInfo Endpoint returns previously consented user profile information to your application. In other words, if the required claims are not returned in the ID Token, you can obtain the additional claims by presenting the access token to the itsme® UserInfo Endpoint. This is achieved by sending a HTTP GET request to the Userinfo Endpoint, passing the access token value in the Authorization header using the Bearer authentication scheme.
This is illustrated in the example below.
Response
200
application/json
The UserInfo Response is represented as a signed and encrypted JWT. So, before being able to extract the claims you will have to decrypt and verify the signature (refer to this page for more information).
-
GET https://oidc.[e2e/prd].itsme.services/clientsecret-oidc/csapi/v0.1/connect/userinfo
The UserInfo Endpoint returns previously consented user profile information to your application. In other words, if the required claims are not returned in the ID Token, you can obtain the additional claims by presenting the access token to the itsme® UserInfo Endpoint. This is achieved by sending a HTTP GET request to the Userinfo Endpoint, passing the access token value in the Authorization header using the Bearer authentication scheme.
This is illustrated in the example below.
Response
200
application/json
The UserInfo Response is represented as a signed and encrypted JWT. So, before being able to extract the claims you will have to decrypt and verify the signature (refer to this page for more information).
Example
Request
GET /userinfo HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG
Response
This is an response example containing all possible claims for a Belgian account:
HTTP/1.1 200 OK
Content-Type: application/json
{
"http://itsme.services/v2/claim/validityFrom": {
"http://itsme.services/v2/claim/BEeidSn": "2018-11-08T00:00:00Z"
},
"sub": "e3xad7upx64grm14ttpnx4c586ve8gy0gp38",
"birthdate": "1978-11-01",
"http://itsme.services/v2/claim/claim_citizenship_as_iso": "BEL",
"gender": "male",
"http://itsme.services/v2/claim/birthdate_as_string": "01.11.1978",
"http://itsme.services/v2/claim/IDDocumentType": "I",
"iss": "https://oidc.uat.itsme.services/clientsecret-oidc/csapi/v0.1",
"http://itsme.services/v2/claim/validityTo": {
"http://itsme.services/v2/claim/BEeidSn": "2028-11-10T00:00:00Z"
},
"http://itsme.services/v2/claim/claim_citizenship": "BE",
"locale": "FR",
"http://itsme.services/v2/claim/issuance_locality": {
"http://itsme.services/v2/claim/BEeidSn": "BRUXELLES"
},
"email": "test@itsme.be",
"http://itsme.services/v2/claim/place_of_birth": {
"city": "Brussels",
"formatted": "Brussels"
},
"address": {
"locality": "TONGEREN",
"street_address": "Jekerstraat 39",
"postal_code": "3700",
"formatted": "Jekerstraat 39 3700 TONGEREN"
},
"email_verified": false,
"http://itsme.services/v2/claim/claim_device": {
"os": "ANDROID",
"appName": "be.bmid.itsme.uat",
"appRelease": "4.0.0",
"deviceLabel": "lucye",
"debugEnabled": false,
"deviceId": "c22de2331dd249bba063afd3507fe3a4f",
"osRelease": "9",
"manufacturer": "LGE",
"deviceLockLevel": "true",
"rooted": false,
"deviceModel": "LG-H870",
"msisdn": "0032485694175"
},
"http://itsme.services/v2/claim/BENationalNumber": "99060427181",
"phone_number_verified": true,
"given_name": "George",
"picture": "https://oidc.uat.itsme.services/clientsecret-oidc/csapi/v0.1/picture",
"http://itsme.services/v2/claim/verificationDate": {
"http://itsme.services/v2/claim/place_of_birth": "2023-04-12T15:02:23Z",
"birthdate": "2023-04-12T15:02:23Z",
"address": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/claim_citizenship_as_iso": "2023-04-12T15:02:23Z",
"gender": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/birthdate_as_string": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/BENationalNumber": "2023-04-12T15:02:23Z",
"given_name": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/claim_citizenship": "2023-04-12T15:02:23Z",
"picture": "2023-04-12T15:02:23Z",
"name": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/IDDocumentSN": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/BEeidSn": "2023-04-12T15:02:23Z",
"family_name": "2023-04-12T15:02:23Z",
"http://itsme.services/v2/claim/physical_person_photo": "2023-04-12T15:02:23Z"
},
"aud": "WXw9DMqkEv",
"http://itsme.services/v2/claim/IDIssuingCountry": {
"http://itsme.services/v2/claim/place_of_birth": "BEL",
"birthdate": "BEL",
"address": "BEL",
"http://itsme.services/v2/claim/claim_citizenship_as_iso": "BEL",
"gender": "BEL",
"http://itsme.services/v2/claim/birthdate_as_string": "BEL",
"http://itsme.services/v2/claim/BENationalNumber": "BEL",
"given_name": "BEL",
"http://itsme.services/v2/claim/claim_citizenship": "BEL",
"picture": "BEL",
"name": "BEL",
"http://itsme.services/v2/claim/IDDocumentSN": "BEL",
"http://itsme.services/v2/claim/BEeidSn": "BEL",
"family_name": "BEL",
"http://itsme.services/v2/claim/physical_person_photo": "BEL"
},
"name": "George Tǎnka",
"http://itsme.services/v2/claim/IDDocumentSN": "431522485012",
"phone_number": "+32 485694175",
"http://itsme.services/v2/claim/BEeidSn": "431522485012",
"family_name": "Tǎnka",
"http://itsme.services/v2/claim/physical_person_photo": {
"format": "image/jpeg",
"value": "/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYFBgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/wAALCADIAIwBAREA/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/AP38ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooorI/4SIf3h+tH/AAkQ/vD9aP8AhIh/eH60f8JEP7w/Wj/hIh/eH60f8JEP7w/Wj/hIh/eH60f8JEP7w/Wj/hIh/eH60f8ACRD+8P1o/wCEiH94frR/wkQ/vD9aP+EiH94frR/wkQ/vD9aP+EiH94frR/wkQ/vD9aP+EiH94frR/wAJEP7w/WuB/wCEj/2xR/wkf+2KP+Ej/wBsUf8ACR/7Yo/4SP8A2xR/wkf+2KP+Ej/2xR/wkf8Atij/AISP/bFH/CR/7Yo/4SP/AGxR/wAJH/tij/hI/wDbFH/CR/7Yo/4SP/bFH/CR/wC2KP8AhI/9sUf8JH/tiuD/AOEiX+/+tH/CRL/f/Wj/AISJf7/60f8ACRL/AH/1o/4SJf7/AOtH/CRL/f8A1o/4SJf7/wCtH/CRL/f/AFo/4SJf7/60f8JEv9/9aP8AhIl/v/rR/wAJEv8Af/Wj/hIl/v8A60f8JEv9/wDWj/hIl/v/AK0f8JEv9/8AWj/hIl/v/rR/wkS/3/1rgf8AhIm/v/rR/wAJE39/9aP+Eib+/wDrR/wkTf3/ANaP+Eib+/8ArR/wkTf3/wBaP+Eib+/+tH/CRN/f/Wj/AISJv7/60f8ACRN/f/Wj/hIm/v8A60f8JE39/wDWj/hIm/v/AK0f8JE39/8AWj/hIm/v/rR/wkTf3/1o/wCEib+/+tH/AAkTf3/1rgv+EjH/AD0P50f8JGP+eh/Oj/hIx/z0P50f8JGP+eh/Oj/hIx/z0P50f8JGP+eh/Oj/AISMf89D+dH/AAkY/wCeh/Oj/hIx/wA9D+dH/CRj/nofzo/4SMf89D+dH/CRj/nofzo/4SMf89D+dH/CRj/nofzo/wCEjH/PQ/nR/wAJGP8Anofzo/4SMf8APQ/nR/wkY/56H864L/hIz/z0b86P+EjP/PRvzo/4SM/89G/Oj/hIz/z0b86P+EjP/PRvzo/4SM/89G/Oj/hIz/z0b86P+EjP/PRvzo/4SM/89G/Oj/hIz/z0b86P+EjP/PRvzo/4SM/89G/Oj/hIz/z0b86P+EjP/PRvzo/4SM/89G/Oj/hIz/z0b86P+EjP/PRvzo/4SM/89G/OuC/4SIf89h+dH/CRD/nsPzo/4SIf89h+dH/CRD/nsPzo/wCEiH/PYfnR/wAJEP8AnsPzo/4SIf8APYfnR/wkQ/57D86P+EiH/PYfnR/wkQ/57D86P+EiH/PYfnR/wkQ/57D86P8AhIh/z2H50f8ACRD/AJ7D86P+EiH/AD2H50f8JEP+ew/Oj/hIh/z2H50f8JEP+ew/OuB/4SQ/89TR/wAJIf8AnqaP+EkP/PU0f8JIf+epo/4SQ/8APU0f8JIf+epo/wCEkP8Az1NH/CSH/nqaP+EkP/PU0f8ACSH/AJ6mj/hJD/z1NH/CSH/nqaP+EkP/AD1NH/CSH/nqaP8AhJD/AM9TR/wkh/56mj/hJD/z1NH/AAkh/wCeprgP+EkX/np+tH/CSL/z0/Wj/hJF/wCen60f8JIv/PT9aP8AhJF/56frR/wki/8APT9aP+EkX/np+tH/AAki/wDPT9aP+EkX/np+tH/CSL/z0/Wj/hJF/wCen60f8JIv/PT9aP8AhJF/56frR/wki/8APT9aP+EkX/np+tH/AAki/wDPT9aP+EkX/np+tH/CSL/z0/WuD/4SP/bH60f8JH/tj9aP+Ej/ANsfrR/wkf8Atj9aP+Ej/wBsfrR/wkf+2P1o/wCEj/2x+tH/AAkf+2P1o/4SP/bH60f8JH/tj9aP+Ej/ANsfrR/wkf8Atj9aP+Ej/wBsfrR/wkf+2P1o/wCEj/2x+tH/AAkf+2P1o/4SP/bH60f8JH/tj9a4H/hIR/eP50f8JCP7x/Oj/hIR/eP50f8ACQj+8fzo/wCEhH94/nR/wkI/vH86P+EhH94/nR/wkI/vH86P+EhH94/nR/wkI/vH86P+EhH94/nR/wAJCP7x/Oj/AISEf3j+dH/CQj+8fzo/4SEf3j+dH/CQj+8fzo/4SEf3j+dH/CQj+8fzrgv+EiH98/nR/wAJEP75/Oj/AISIf3z+dH/CRD++fzo/4SIf3z+dH/CRD++fzo/4SIf3z+dH/CRD++fzo/4SIf3z+dH/AAkQ/vn86P8AhIh/fP50f8JEP75/Oj/hIh/fP50f8JEP75/Oj/hIh/fP50f8JEP75/Oj/hIh/fP50f8ACRD++fzrgf8AhJf+mn60f8JL/wBNP1o/4SX/AKafrR/wkv8A00/Wj/hJf+mn60f8JL/00/Wj/hJf+mn60f8ACS/9NP1o/wCEl/6afrR/wkv/AE0/Wj/hJf8App+tH/CS/wDTT9aP+El/6afrR/wkv/TT9aP+El/6afrR/wAJL/00/Wj/AISX/pp+tH/CS/8ATT9a4H/hIR/z0P50f8JCP+eh/Oj/AISEf89D+dH/AAkI/wCeh/Oj/hIR/wA9D+dH/CQj/nofzo/4SEf89D+dH/CQj/nofzo/4SEf89D+dH/CQj/nofzo/wCEhH/PQ/nR/wAJCP8Anofzo/4SEf8APQ/nR/wkI/56H86P+EhH/PQ/nR/wkI/56H86P+EhH/PQ/nR/wkI/56H864L/AISNf+e1H/CRr/z2o/4SNf8AntR/wka/89qP+EjX/ntR/wAJGv8Az2o/4SNf+e1H/CRr/wA9qP8AhI1/57Uf8JGv/Paj/hI1/wCe1H/CRr/z2o/4SNf+e1H/AAka/wDPaj/hI1/57Uf8JGv/AD2o/wCEjX/ntR/wka/89q4L/hIz/wA9v1FH/CRn/nt+oo/4SM/89v1FH/CRn/nt+oo/4SM/89v1FH/CRn/nt+oo/wCEjP8Az2/UUf8ACRn/AJ7fqKP+EjP/AD2/UUf8JGf+e36ij/hIz/z2/UUf8JGf+e36ij/hIz/z2/UUf8JGf+e36ij/AISM/wDPb9RR/wAJGf8Ant+oo/4SM/8APb9RR/wkZ/57fqK+w/8AiGO/4Lt/9GNH/wAOZ4Y/+WdH/EMd/wAF2/8Aoxo/+HM8Mf8Ayzo/4hjv+C7f/RjR/wDDmeGP/lnR/wAQx3/Bdv8A6MaP/hzPDH/yzo/4hjv+C7f/AEY0f/DmeGP/AJZ0f8Qx3/Bdv/oxo/8AhzPDH/yzo/4hjv8Agu3/ANGNH/w5nhj/AOWdH/EMd/wXb/6MaP8A4czwx/8ALOj/AIhjv+C7f/RjR/8ADmeGP/lnR/xDHf8ABdv/AKMaP/hzPDH/AMs6P+IY7/gu3/0Y0f8Aw5nhj/5Z0f8AEMd/wXb/AOjGj/4czwx/8s6P+IY7/gu3/wBGNH/w5nhj/wCWdH/EMd/wXb/6MaP/AIczwx/8s6P+IY7/AILt/wDRjR/8OZ4Y/wDlnR/xDHf8F2/+jGj/AOHM8Mf/ACzo/wCIY7/gu3/0Y0f/AA5nhj/5Z0f8Qx3/AAXb/wCjGj/4czwx/wDLOv67aKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK/9k="
},
"nbf": 1681314190,
"exp": 1681314490,
"iat": 1681314190
}
Revoke Request
-
Not applicable.
-
POST https://oidc.[e2e/prd].itsme.services/clientsecret-oidc/csapi/v0.1/connect/revoke
The Revocation Endpoint enables your application to notify itsme® that a previously obtained access token is no longer needed and MUST be revoked.
Parameters
tokenREQUIREDThe access_token
previously obtained that you want to revoke.token_type_hintOPTIONALA hint about the type of the token submitted for revocation. You MAY pass this parameter in order to help itsme® to optimize the token lookup. If the server is unable to locate the token using the given hint, it MUST extend its search across all of its supported token types. If used, this is set to access_token
because itsme® API don't support refresh tokens.Response
200
itsme® responds with HTTP status code 200 if the token has been revoked successfully or if the client submitted an invalid token.
Example
-
Not applicable.
-
Request
POST /connect/revoke HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
Response
HTTP/1.1 200 OK