Use industry standards to power developer access to DailyPay APIs and Embedded Experiences, minimizing user and developer surprise and maximizing user-session reuse.
Use nested OIDC flows to authenticate users for DailyPay using the developer’s Identity Provider.
Developers will use OAuth2.0 Authorization Code Flow + PKCE and OIDC to retrieve access and refresh tokens for use with DailyPay APIs and DailyPay Elements: see Authorization Code Flow.
Within the Authorization Code Flow, DailyPay will reach out to the partner’s Identity Provider to identify the user. DailyPay prefers an OIDC Identity Provider wherever possible, and our Auth Server will initiate its own, nested OAuth2.0 Authorization Code Flow to the partner’s Auth Server. If the partner’s Auth Server identifies an active session, the experience is seamless and potentially zero-touch for the end user, and DailyPay will match the subject identifier from the active session to an identity loaded into DailyPay from the Data Exchange or elsewhere. DailyPay Auth Server will then return the payload needed to complete the Authorization Code Flow and obtain an access token for the API or Element.
Note: An important prerequisite is that a unique identifier for each user is shared across systems, usually through the DailyPay Data Exchange.
The following diagram details all steps of the OIDC-in-OIDC or SAML-in-OIDC approach.
In order to establish a trust relationship, DailyPay needs a way to verify the authenticity of the user session that wraps the Authorization Code Flow. OAuth2.0 with OIDC provides a set of mechanisms to establish that trust relationship. Below are the critical elements, that even without full OIDC support, are advised or required to create the highest security and lowest friction user auth experience.
- Accept an OAuth2.0-style GET request (6), and return an authorization code using an http redirect to the DailyPay callback endpoint (8).
- If the user is already logged in with an active session (1), the authorization server should detect the session (7) and return the authorization code without prompting the user for additional information.
- Allow only the DailyPay preregistered client to exchange that authorization code (10) for an access token (11), using a client secret or a signature using our public key.
- Populate the access token or an OIDC-style JWT Identity Token with signed claims, and provide a way to validate those claims.
- The claims must include the shared unique identifier for the user (12).