Open christiansmith opened 8 years ago
+1 for this feature.
Although this feature looks like it concerns only the protected apps (RP), it is a very nice addition to anvil. Because during a social login, Anvil is indeed the RP for another OP (e.g. Google). Therefore if a protected app already knows the final IdP that a given user wants to use, it is nice that anvil can find a way to bypass its own account chooser screen containg the list of supported OUTBOUND IdPs. Adding an "iss" parameter on the /authorize request is an OIDC compliant way for a registered client to request an Outbound authentification to a registered idP. Only Anvil will understand this parameter, because it is the only IdP (to my knowledge) that allows "Outbond" authN scenarios. Other IdPs would discard this parameter, as they should.
Let me add an important point: in scenarios where the outbound IdP is in the same security realm as the interactive user, the outbound IdP can implement "auto-login" strategies with technologies such as Kerberos, NTLM, or even siteminder, thus providing to the interactive user a passwordless experience.
I would however recommend a configuration option that allows the admin to enable the iss parameter for "authenticated registered" clients only (let it be the default setting) This would force that the iss parameter is only active for registered apps AND grant types that enforce client authentication (HTTP_BASIC for autorisation_code flow). Knowing that the client-id can be spoofed in the implicit flow, this would allow an admin to say that he doesn't want any (JS or not) client to attempt that operation... thus preventing phishing attempts from unregistered apps... Please note that the consequence of such a phishing attempt would only be that the user has proven is identity to the unregistered app (no password leakage, and no scopes other than "profile" could be added to the access_tokens) But that's bad enough if you want my opinion. However, it might not be so important to some very small IdPs (think university... Etc), especially knowing that these attempts could be made anyways, even if anvil shows an account chooser login form.
And of course, this has no consequences when IdPs are chained within the same secuity realm. E.g a global intranet with several local IdPs, or a federation of intranets through secure links.
So in case i was not clear, i'm still very very much in favor of that feature!!! ;)))
http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin