Initiating Login from a Third Party
christiansmith opened this issue · comments
In some cases, the login flow is initiated by an OpenID Provider or another party, rather than the Relying Party. In this case, the initiator redirects to the RP at its login initiation endpoint, which requests that the RP send an Authentication Request to a specified OP. This login initiation endpoint can be a deep link at the RP, rather than a default landing page. RPs supporting OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] register this endpoint value using the initiate_login_uri Registration parameter.
The party initiating the login request does so by redirecting to the login initiation endpoint at the RP, passing the following parameters:
iss
REQUIRED. Issuer Identifier for the OP that the RP is to send the Authentication Request to. Its value MUST be a URL using the https scheme.
login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in. If the client receives a value for this string-valued parameter, it MUST include it in the Authentication Request as the login_hint parameter value.
target_link_uri
OPTIONAL. URL that the RP is requested to redirect to after authentication. RPs MUST verify the value of the target_link_uri to prevent being used as an open redirector to external sites.
The parameters can either be passed as query parameters using the HTTP GET method or be passed as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method.
Other parameters MAY be sent, if defined by extensions. Any parameters used that are not understood MUST be ignored by the Client.
Clients SHOULD employ frame busting and other techniques to prevent End-Users from being logged in by third party sites without their knowledge through attacks such as Clickjacking. Refer to Section 4.4.1.9 of [RFC6819] for more details.
http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin
+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!!! ;)))