Third Party IDP Mapping
While Mydex offers the use of the MydexID as a form of authentication, both on Mydex-operated and Subscriber services acting as 'Relying Parties' via OpenID Connect, Mydex also recognises that many of our members (People) have existing DigitalIDs with third party identity providers (IDPs). These may be government-operated or private sector providers.
Mydex can support integration with third party IDPs in order to let the member login with that third party IDP and still be able to map their account to their MydexID and PDS. A MydexID is still required to be held by the member in order to for this to successfully link with their PDS.
A Member can review at any time which third party IDPs they have mapped to their MydexID, and remove if they wish, using their Member Account Management Services.
How it works
There are several scenarios to consider. In all three scenarios, the journey begins with the member starting a login journey in an application that supports authentication with the Third Party IDP.
A person seeking to map a Third Party IDP may also be registering a DigitalID at that Third Party IDP for the first time, as part of the journey on your application. Often a Third Party IDP will allow a registration option on the page that the authentication flow initiates. Once that third party IDP registration process is complete, either Scenario 1 or Scenario 2 can be invoked to complete the mapping.
Scenario 1: The member already has a MydexID but has not yet mapped it to their Third Party IDP
In this scenario, the member signs in to the Application using the Third Party IDP. The Application learns the unique identifier of the member from the Third Party IDP, for example the 'sub' attribute of an OIDC ID token.
The Application then performs an authenticated API request to the Mydex IDaaS API to check if that identifier (sub) exists in the Mydex IDaaS system already (mapped to a MydexID). In Scenario 1, the sub has not yet been mapped to the MydexID, so an error is returned.
The Application should now present a mapping screen to the member, offering to map their Third Party IDP to a MydexID. In Scenario 1, the member has a MydexID already, so chooses 'I have a MydexID'. The Application should then commence an OIDC journey with the Mydex OIDC, adding the mapping=$thirdpartyidp query parameter to the OAuth2.0 auth request.
The member is taken to the Mydex Login and Consent application (LaCa) to enter their MydexID and password, thereby proving they own those MydexID credentials. As part of this process, the LaCa performs its own OIDC flow with the Third Party IDP to obtain the sub.
Upon successful submission of valid MydexID credentials, the LaCa instructs the IDaaS API to store the sub in the mapping backend for this MydexID. The Mydex OIDC authentication flow completes and the Application can obtain the mydexid claim and start the Application session as normal.
Flow diagram
Scenario 2: The member does not yet have a MydexID
In this scenario, the member signs in to the Application using the Third Party IDP. The Application learns the unique identifier of the member from the Third Party IDP, for example the 'sub' attribute of an OIDC ID token.
The Application then performs an authenticated API request to the Mydex IDaaS API to check if that identifier (sub) exists in the Mydex IDaaS system already (mapped to a MydexID). In Scenario 2, the sub has not yet been mapped to the MydexID, so an error is returned.
The Application should now present a mapping screen to the member, offering to map their Third Party IDP to a MydexID. In Scenario 2, the member does not yet have a MydexID/PDS, so chooses 'Register a MydexID'. The Application should then commence an OIDC journey with the Mydex OIDC, adding the action=register and mapping=$thirdpartyidp query parameters to the OAuth2.0 auth request.
The member is taken to the Mydex Login and Consent application (LaCa) and a registration form is shown. The member registers a new MydexID and PDS by providing the required registration details. As part of this process, the LaCa performs its own OIDC flow with the Third Party IDP to obtain the sub.
Upon successful registration of the MydexID, the LaCa instructs the IDaaS API to store the sub in the mapping backend for this new MydexID. The Mydex OIDC authentication flow completes and the Application can obtain the mydexid claim and start the Application session as normal.
Flow diagram
Scenario 3: The member has a MydexID and the Third Party IDP sub has already been mapped
In this scenario, the member signs in to the Application using the Third Party IDP. The Application learns the unique identifier of the member from the Third Party IDP, for example the 'sub' attribute of an OIDC ID token.
The Application then performs an authenticated API request to the Mydex IDaaS API to check if that identifier (sub) exists in the Mydex IDaaS system already (mapped to a MydexID). In Scenario 3, the sub has already been mapped to the MydexID, via either a Scenario 1 or Scenario 2 journey completed at a prior time. The MydexID is returned in the response from the IDaaS API.
The Application can treat the returned MydexID as if it were a claim, and start the Application session as normal. There is no need to commence a Mydex OIDC journey at all to prove MydexID credentials.
Flow diagram
How to get started
Contact Mydex to inquire about which Third Party IDP services are currently supported. If the Third Party IDP is not yet supported, Mydex may be able to accommodate it, but will need to engage with that IDP to obtain valid credentials (typically OIDC/OAuth2.0 credentials) to support the mapping journeys.
In addition, Mydex will provide the Subscriber with an OAuth2.0 client that is scoped accordingly in order to support mapping lookups of the relevant sub via the Mydex IDaaS API.