Validate usefulness of non-interactive OAuth 2 code grant through trusted apps & SAML SSO with isPassive=true

• Type: Spike
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: None
• Fix Version/s: None
• Component/s: Application Security > OAuth2, Application Security > SAML
• Labels:
  • 7.4-could
  • 7.4-dxp
• Epic Link: SAML enhancements

From the SAML 2.0 Core spec.

IsPassive [Optional] A Boolean value. If "true", the identity provider and the user agent itself MUST NOT visibly take control of the user interface from the requester and interact with the presenter in a noticeable fashion. If a value is not provided, the default is "false".

It is envisaged that a Liferay OAuth2 provider connected to a SAML IDP for user authentication when handling an Authorization Code grant, could use this parameter. It would guarantee that the OAuth 2 client will get a machine readable success/error response.

If at the same time we would introduce a similar parameter for the OAuth 2 code grant flow itself, to prevent a prompt (i.e. HTML response) for user authorization, the entire flow could complete in a non-interactive fashion. Just as a series of HTTP redirects, resulting in a final response containing the OAuth 2 authorization code.

We have previously discussed this as "trusted applications". For example a JavaScript / React app running on a different domain/server to the Liferay OAuth 2 provider, but still owned by a single legal entity (and likely in the same network).

Conditions:

• This proposal assumes the use/support of the SAML redirect binding.
• The client app uses the same IDP for user authentication (but it could use a different SSO protocol than SAML, that better suits the clients capabilities. Possibly OpenIdConnect, though Liferay is currently not a OIDC provider).
• The non-interactive OAuth 2 Authorization Code Grant flow must have sufficient CSRF protection