So far the account chooser has been agnostic about how the websites authenticated the user, i.e. it could use passwords, OpenID, SAML, OpenIDConnect, etc. That also had the nice property that IDPs did not need to change to support an account chooser.
However there is one advanced feature that does require specific protocol integration with the IDP. The goal is to simplify the UX for the scenario where the user is visiting a website for the first time and the website only needs to get the user's verified email address (and maybe public profile information) from the IDP. Traditionally that takes 3 clicks:
- Click sign-in on a site
- Click an entry in the central account chooser
- Click an OK button on the IDPs consent page
Both steps 2 and 3 have the same purpose, i.e. get the user to consent to share their email address with the site. So the advanced feature we want to implement is to skip step 3 and enable the IDP to determine that the user already gave their consent in step 2. We call this the "2-click flow" flow to differentiate it from the regular "3-click flow."
We have had a basic demo of this (see the old email below), but now it is much easier to try out. The app at
http://2clickdemo.appspot.com/mail.jsp acts as a wrapper around the Gmail login flow and IDP. So log into that app using a Gmail account that is not configured to automatically log into the demo websites. You can use a new account for that testing, or visit
https://accounts.google.com/b/0/IssuedAuthSubTokens on an existing account to revoke access to those demo sites. Once you have logged into the app, you can visit any of the demo sites and try to sign in with that Gmail address. Once you click it in the central account chooser you will notice that you are immediately logged into the demo sites without needing to see an additional consent screen.
Technically this is done by having the central account chooser request an OpenID Connect idtoken from the IDP whose "audience" is configured to be the website that started the sign-in flow. The IDP has to whitelist the account chooser to enable it to request these tokens. We are now brainstorming the different attack vectors on this design to see how the protocol needs to be modified. Note that since this is a demo, it is not using real idtokens issued by the Google IDP. As a side effect, that means that if you log out of Gmail, the account chooser on your browser can continue to issue demo idtokens, so this is best tested in an incognito/private-browsing window. Soon we will add a URL on that app which you can use to reset it more easily.
<other text deleted>
We also have a demo of a very slick feature that lets the user avoid seeing a consent page on the IDP. As long as the RP is only requesting the users' email/photo/name, it can ask the CDS to request an OAuth token directly from the IDP. The IDP can choose to trust that the CDS got the user's consent to share that information by showing an account chooser where the user clicked an entry. I will work on a Youtube video to show this, but you can try it yourself. First, create an account on our mock IDP (
gitkit-idp.appspot.com) or just use the account "
a...@gitkit.com" (password: 123) and sign in with this account. Second, go to
http://gitkit-tool.appspot.com to add this account to CDS. (NOTE: Do not input the provider ID. Also you can leave the photo/name fields blank and they will be updated later.) Third, got to the demo RP at
http://gitkit-redirect.appspot.com, click the "sign in" button and click this account on the CDS account chooser. The CDS will get the IDP assertion using an embedded IDP iframe invisibly and pass it to the demo site. The site will use this assertion to sign in the user without redirecting to the IDP. Note that if you click the account on the account chooser while you are not signed into the mock IDP site with it, the widget properly fails to sign the user in. This is the only feature of the CDS that is protocol specific, and it requires the use of OpenID Connect by the IDP.