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
- 2.Create an application that will create OAuth credentials.
Origin URLis 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.
Redirect URLis called from the identity provider after a user has been authenticated so your application can retrieve the identity details.
- 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.
- 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
- 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
issshould 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-configurationendpoint. 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.