Standard - No way of doing IdP initiated login defined

[Nat Sakimura]

Currently, we do not have a standardized way of doing IdP initiated login.

[John Bradley]

To get this to work the id_token needs to indicate that it is a IDP initiated login and have some relay state parameter so the RP knows what the landing page is.

The problem is that the client needs to know to ignore state and nonce.

[Former user]

What would be a typical use case for such IdP initialited logins?

[Brian Campbell]

I believe it's very important that connect provide a fully standardized/documented way to do IdP init SSO.

[Michael Jones]

The WG agrees that this is important to specify. Many cloud use cases will expect to be able to do this - especially becuase it's possible in SAML.

A pre-existing relationship with the client may be necessary. Related questions that would have to be solved is what client_id to use and what relay state to provide. Out-of-band registration may be necessary.

[John Bradley]

Re #601 add initiate_login_uri for unsolicited request

→ <<cset f7670f9c7702>>

[John Bradley]

Re #601 changed initiate_login_uri to match connect parameter usage, Account chooser passes things in a JSON object on the callback, it is the client JS that POSTs them back to the client, so that may as well use our naming.

→ <<cset 3e30d4a6ef3e>>

[John Bradley]

Re #601 add Initiating login at a client from a third party

→ <<cset a1a5dd66c522>>

[John Bradley]

Reviewed by Mike. close ticket