SL1 - Is Confidential Client a MUST in OpenID Connect IPSIE SL1 Profile?

[mcguinness]

Aaron currently modeled the initial draft of an IPSIE OIDC profile for SL1 based off FAPI (https://github.com/aaronpk/ipsie-openid-sl1) where Confidential Client is a MUST.

A lot of SSO with OIDC today uses just the claims in the ID Token and doesn't really make use of Access Token for UserInfo endpoint and Refresh Token for the OP. FAPI is specifically trying to profile secure clients to obtain access tokens to highly regulated API endpoints. Access Tokens are the P0 in FAPI.

I could see a valid enterprise scenario where only offline_access with the issuance of a Refresh Token requires a confidential client as long as the tokens are issued via backchannel and access tokens for UserInfo are short-lived (IPSIE can define max lifetime) and protected with DPOP.

If an enterprise RP chooses to implement a public client and willing to use PKCE with a HTTPS callback to their origin that has been registered with the IDP (and verified through IdP's ISV/app boarding processes) and just needs to SSO a user to create a local app session but doesn't need to sync identity data offline or access other secure APIs at the IdP (common for IdPs that are also platforms like Google and Entra+Graph) not needing the overhead of a confidential client for SL1 conformance. Enterprises already need to trust that the RP has correctly implemented TLS to secure the app's traffic. We could define additional DNS/PKI requirements for the RP callback endpoint as we are doing for the OP if we wanted for additional security guarantees.

I would like to better understand why we want to require a confidential client for the SL1 SSO use case. Supporting public clients for SL1 SSO helps the enterprise IMHO by lowering the adoption friction by RPs that may be hosted with different tech stacks, clouds, providers, etc). Securely managing secrets is hard and if a enterprise app doesn't have to manage client credentials for every customer's IdP then there is less to get wrong.

[aaronpk]

My main concern about allowing public clients is that enterprise SSO typically doesn't include a consent screen, since it's only providing identity claims and not an access token to access other resources. Without a consent screen, the user is sent back immediately to the application. Without credentials, this opens up some interesting possibilities of app impersonation, which would be invisible because of the lack of the consent screen.

I would want to do a very thorough security analysis of what security properties we'd be losing by not requiring client credentials. My takeaway from the discussions in the last OSW is that these things are never as straightforward as they seem at first glance.

[aaronpk]

One potentially useful data point is that the Okta Integration Network doesn't allow public clients at all https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-limitations

[mcguinness]

Another datapoint is SAML SSO the enterprise gold standard is effectively a public client :)

+1 do doing the very thorough security analysis. If we need we need it. Just want to make sure we have good reasoning to add the overhead which doesn't exist today with SAML.

[aaronpk]

In either case, in the spirit of interoperability, I would expect that the outcome is either IPSIE OIDC clients never have credentials or always have credentials. We want to avoid an enterprise app needing to look up the docs on whether a particular IPSIE-supporting IdP requires credentials for the client or not.

[mcguinness]

One potentially useful data point is that the Okta Integration Network doesn't allow public clients at all https://developer.okta.com/docs/guides/submit-app-prereq/main/#oin-limitations

I know the backstory 😉 but keep in mind that OIN also incorporates many scenarios where an RP needs an access token to the Okta API as resource server. ISVs can also just have customers create a custom OIDC registration which some do.

[mcguinness]

outcome is either IPSIE OIDC clients never have credentials or always have credentials

For all levels or could this only be required at a higher level? I was focused on SL1 level of conformance which is lowest level for an "enterprise" app.

If an app can also support SAML for IPSIE compliance (TBD) do we need the same security properties for the same level as well?

This might be a good discussion for a WG call.

[aaronpk]

I was thinking within a level, but it's an interesting question as to whether an app that wants to move from SL1 to SL2 would then have to also add credential management. Definitely a good WG call topic.