OpenID Connect implementation via PING Identity, custom authentication page via authorization_endpoint

Question

We have our application (App-A) being built by Enterprise-A, which needs to use a third-party IDP (Ping Identity) to federate the authentication of users. In addition to allowing authentication of users via Ping to login into our App-A, we also need to allow App-B built by another Enterprise-B to access information about our users on behalf of them (offline-access) once our users authenticate into our system and provide the required consent. Clearly, OpenID Connect with Authorization Code Flow seems to be the way to go.

Now, while logging in our users directly to our App-A, and also while users go through App-B and provide offline_access consent to App-B for them to access user's information from App-A, "we have a requirement" that the authentication page needs to be fully customized and themed to our App-A's product theme/colors.

App-B (Enterprise-B) also asks that we or our IDP host a "/.well-known/openid-configuration" endpoint that lists authorization_endpoint, token_endpoint, userinfo_endpoint, scopes_supported (including offline_access scope) among other things (as is OIDC standards).

Now my question is, when App-B redirects a user to login to our App-A and provides consent to allow App-B to access their info from App-A, I understand that App-B will redirect the user to the URL pointed to by "authorization_endpoint" in "/.well-known/openid-configuration" endpoint to challenge the user to authenticate. Now in order to have a custom-themed login screen what are the options?

a) Should our IDP (Ping Identity) build a custom login screen and consent screen for us, or b)is there a way where we can build this custom-themed login screen which upon successful authentication and consent can return an authorization_code to App-B from our IDP?

P.S: Our frontend (on App-A) is an Angular SPA, and wrapped via capacitor, and runs on Web, iOS, and Android. We have our backend (Resource Server) available as REST API that can do JWT validation of the access_token via our IDP.

Answer 1

I would get the roles a bit clearer here, in terms of ownership:

COMPONENT ROLES (ENTERPRISE A)

Enterprise A uses an authorization server (AS) to protect its data:

• App A runs a code flow to AS A
• The user authenticates
• AS A issues tokens to App A
• App A sends an access token to its APIs

APIs from Enterprise A can then authorize correctly, since tokens issued, and their scopes and claims, are controlled by Enterprise A.

COMPONENT ROLES (ENTERPRISE B)

These should be identical to those for Enterprise A, and be applied to App B and its APIs.

AUTHENTICATION

Authorization servers also have IDP capabilities. Here are some examples:

• Enterprise A provides its own branding and preferred authentication methods in its AS for its users
• Enterprise B provides its own branding and preferred authentication methods in its AS for its users
• Logins from App A can do a federated login via AS B
• AS B will then issue tokens to AS A, after which AS A continues to issue its own tokens to App A

One way to implement this is to configure AS A to prompt for a user identifier such as an email. It can then look up the enterprise of the user, then redirect to the corresponding IDP to authenticate the user.

ANSWERS

• App B does not redirect to App A. Instead users from Enterprise B use App A, which redirects to AS A, which redirects to AS B. Those users then login in the preferred way.

• In your case Ping Identity is AS A. You will not build a login screen for Enterprise B. Instead AS B is registered as an IDP in AS A, and AS A is registered as a client in AS B. This enables the federation to work.

It may sound complicated, but this is a powerful behaviour, requiring zero code. I always recommend working backwards from what APIs need, since OAuth is primarily about protecting data, rather than authentication.