Relying Party User Guide
Getting started as a Relying Party.
Start with the Architecture Overview to become familiar with the key concepts for the IDPartner ecosystem.
IDPartner provides a Relying Party consent-based access to a Customer’s Identity details. The identity details can be provided by any of the Identity Providers within the IDPartner Network.
Every identity provider in the IDPartner network implements a FAPI-compliant OIDC interface. To ensure that all relying parties in the IDPartner Network are able to interoperate successfully they are required to implement a FAPI OIDC Interface. Relying parties, therefore, need to create a FAPI OIDC Client to communicate with the provider.
Relying parties can use our NodeJS library to interact with the APIs but since it is a standard OIDC interface developers can use other libraries available across different languages to help implement an OIDC Client.
Installing IDPartner into your web application requires installing two components
- 1.
- 2.
- 1.
- 2.Create an application that will create OAuth credentials.
- The
Origin URL
is used in conjunction with the IDParter button. When an end-user pressed the button they are redirected to the origin URL to begin the OIDC authorization code flow. - The
Redirect URL
is called from the identity provider after a user has been authenticated so your application can retrieve the identity details.
- 3.
- 4.Create the backend that contains two routes. The URLs of these should be defined when you create an Application from the IDPartner Console.
- 1.Origin endpoint - Called after the button click to start the authorization flow and is also called after an identity provider is selected. i.e.
/auth
- 2.Redirect callback endpoint - OIDC Callback URL that the identity provider calls after authentication with an authorization code that you can exchange for the identity information. For example
/auth/callback
- 5.In your backend application within the origin URL route, you need to call the account selection API "GET https://auth-api.idpartner.com/oidc-proxy/auth/select-accounts" with your client id and visitor id (passed as query params to origin URL)
- 6.After the user has selected a provider the issuer URL and ID are returned back to the origin URL. The query parameters contain an
iss
andidp_id
- 1.The
iss
should be stored in session since it should match the issuer URL in the redirect callback URL later. This is an important security measure.
- 7.If an issuer URL is present in the query parameter your application should return the request metadata from the
/.well-known/openid-configuration
endpoint. The metadata returned contains all the algorithms and endpoints you need to securely start a request and receive claims. - 8.Create a FAPI OIDC Client from the metadata returned from the well-known endpoint of the issuer. There are many libraries that support creating an OIDC client across different languages
- 9.After the end-user has successfully authenticated, the IDP calls the redirect URL with a code.
- 10.The Relying Party exchanges the authorization code for the identity data from the OIDC token endpoint.
Last modified 16d ago