OpenID Connect (OIDC) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. It’s uniquely easy for developers to integrate, compared to any preceding Identity protocol.
OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure verifiable, answer to the question: “What is the identity of the person currently using the browser or native app that is connected to me?”
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users
If your application supports dynamic discovery, then point it to:
https://api.iproov.dev/oidc/v1/.well-known/openid-configuration
Otherwise, enter the endpoints manually:
authorization: https://api.iproov.dev/oidc/v1/authorize
token: https://api.iproov.dev/oidc/v1/token
revocation: https://api.iproov.dev/oidc/v1/token/revoke
end session: https://api.iproov.dev/oidc/v1/logout
userinfo: https://api.iproov.dev/oidc/v1/userinfo
jwks: https://api.iproov.dev/oidc/v1/keys
iProov supports the new backchannel logout protocol. The backchannel logout URL is specified in the applications section of the iPortal.
iProov supports the forthcoming frontchannel logout protocol. The frontchannel logout URL is specified in the applications section of iPortal.
To facilitate integration of iProovID, and to reduce the size of QR-codes, we
have added support for pre-defining query-parameters for QR-codes in our admin
interface. The parameters are defined for each application in the
section Pre-loaded Query
The QR-code can then be created entirely client-side and must contain the
following parameters separated by the dot (.
) character:
client_id
state
nonce
If PKCE is used (which we recommend), then those parameters also need to be added:
code_challenge
code_challenge_method
All other parameters needs to be added in the admin interface.
Since the QR-code is scanned by the user with the iProovID-app, the page needs to communicate with the iProov oidc-backed so that it gets notified when the user has scanned the code and approved the sharing of information. This is done using a socketio connection to api.iproov.com.
To make this more clear, we have provided sample code in python on github for an RP that uses pre-loaded QR-codes to login. More information in the Readme file and the specic code in the 2_Auth_Flow_Preloaded_Qrcode subdirectory
If the value for display
in the call to authorize is authref
, then a number
of values are returned to facilitate the building of a custom QR code page.
Value | Description |
---|---|
qrlink | The link in the QR code. This is useful if you are using your own library to build the QR code. |
qrcode | If instead you want an image link to a generated QR code, then use this value. The link supports the extra query parameters scale , module_color and background to further define the size of the QR code and the colors used in it. The default value for scale is 3. module_color and background colors are given as RGB colors. A sample query could be ?scale=3&module_color=000000&background=FFFFFF . |
applink | The link used in a button to trigger iProovID when used on a mobile device, as in this case the QR code can’t be read. |
qrauth | The link to the authorization page created by iProov, which in turns display the qrcode. |
expires_in | The validity (in seconds) of the QR code. |
expires_at | The UTC timestamp in seconds when the QR code will expire. |
session | The OIDC session identifier which is used in the registration call to socketio |
server | The server that should be used for connecting using socketio |