Sequence diagram shows provider credential leaked to Liferay

[mcgitty]

https://github.com/finalist/liferay-oidc-plugin/blob/master/doc/sequence-diagram.png

Say the Liferay site with this plugin is configure to authenticate via Google (provider) per README.md. The sequence diagram above shows the browser uses the Liferay login page to collect the user's Google account name and password. The Liferay filter then takes over and completes the entire protocol with Google, which suggests that:

1. The Google account name and password is leaked to the relying party (Liferay), which defeats the purpose of OAuth.
2. The browser receives no OAuth artifacts from Google (provider), which prevents the browser from single sign-on to another site that also use Google as provider.

Are these true?

[gvanderploeg]

Hi Michael,

No, these are not true, luckily :-)

The sequence diagram above shows the browser uses the Liferay login page to collect the user's Google account name and password.

Incorrect. The sequence diagram shows that the browser GETs /c/portal/login, which does not render the login-portlet, but instead redirects to a page at the Identity Provider (Google in your case). There is no code/configuration in this plugin that takes credentials from the login portlet and feed them to some external site. That would indeed defeat the whole purpose. The login portlet could however be used side by side with OIDC login, but then you should only fill in 'local' (Liferay native) credentials in this form, and not Google's.

If you experience that the login-portlet is shown where you'd expect Google login, please make sure you have configured your Liferay correctly (and to repeat, do not place the login-portlet anywhere unless you want both OIDC and local login to work).

[mcgitty]

Thanks for clarifying 1. What about 2? The diagram shows that the browser is not involved at all.

[gvanderploeg]

The diagram says 'OpenID Connect auth flow, simplified'. It's exactly in this part where the browser definitely is involved. This is a perfectly standards-compliant OpenID Connect (and thus OAuth 2.0) flow, refer to the spec for details on this.

On Wed, 12 Dec 2018 at 22:30, Michael Chen notifications@github.com wrote:

Thanks for clarifying 1. What about 2? The diagram shows that the browser is not involved at all.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/finalist/liferay-oidc-plugin/issues/37#issuecomment-446751184, or mute the thread https://github.com/notifications/unsubscribe-auth/ABG69nAe9-GpFOpGvtaCbP--TL8skcbLks5u4XVagaJpZM4ZOal9 .

-- http://www.finalist.nl

[mcgitty]

For 2, I am referring to these arrows of the diagram starting or ending at "OpenID Connect Servlet Filter", not to or from "Browser":

• authorizationRequest
• response with code
• tokenRequest(code)
• access token

This is question is only about this particular diagram of this project: https://github.com/finalist/liferay-oidc-plugin/blob/master/doc/sequence-diagram.png

[gvanderploeg]

Ad 2.: this is indeed true: the browser receives no OAuth artifacts. Completely in line with OpenID Connect / OAuth 2.0, the authorization flow is intended for 1 client application (Liferay in this case). Other clients must perform the SSO-'dance' themselves with the Identity Provider.

However, it is completely up to the Identity Provider (Google in your question) to speed up the identification/authentication flow by setting (session/persistent) cookies with the browser, so the next SSO-interaction (for client nr 2) will take place with only a few redirects and no real user interaction (unless new consent has to be given in case of a new client application)

So again, no OAuth artifacts for the browser (as specified), but probably indeed a browser cookie to speed up subsequent SSO-logins.