Hi Stan, Looking a bit more OIDC 3rd party initiated login, I think we can have these 2 scenarii: = Scenario 1  I want to initiate login from a 3rd party to a sample OIDC RP which uses KC as Authorization Server.Solution: In this case, all 3rd implementation burden is for my OIDC RP app [1]. -> nothing to do on KC side for this scenario. = Scenario 2 I configure KC as a OIDC RP for an external IDP (i.e. Okta) *and* I want to do a idp (okta) initiated flow to KC which ultimately will foward to a sample OIDC RP using KC as AS (and okta as idp). This is the scenario of my PR: I add the sample OIDC RP in okta dashboard (previously I configured SAML initiated IDP for that), and when I click on this link I want to be automatically loggedin the sample OIDC RP. Solution 1: Using OIDC 3rd party initiated login, we could implement this flow in the following way:- in KC, we add a initiate_login_uri to the sample OIDC RP- in KC, any oidc idp will be associated with a initiate_login_uri with a uri fragment for every OIDC RP (i.e. http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/sam... in Okta dashboard, we can perhaps integrate OIDC 3rd party initiated login with a link like: http://localhost:8080/auth/realms/realm1/broker/okta/endpoint/clients/sam... means, when we click on this link in okta dashboard (we're already logged to okta):1. okta initiates OIDC 3rd party login with KC, 2. KC initiates OIDC authentication flow with okta and gets valid id_token from okta3. KC detects from the URL that it needs to initiate a 3rd party login to sampleapp using target_link_uri=http://sampleapp.com, and initiates such login4. sampleapp initiates OIDC authentication flow with KC5. sample app gets valid AT, IT from KC Solution 2: But perhaps, this use case can already be done using functionnality available in KC, if we set the dashboard URL in okta to something like:http://sampleapp.com?kc_idp_hint=okta&iss=http://localhost:8080/auth/realms/realm1&&target_link_uri=http://sampleapp.comThen sampleapp just needs to handle 3rd party initiated login *and* propagate the kc_idp_hint to KC when starting the authentication flow. Not sure if Okta allows adding such URL in the dashboard (I don't have anymore access to Okta). Looking at okta docs [2], I would say no. I'm very sorry, those are just some thoughts and I cannot check if solution 1 or 2 would work with Okta (no more access and not very much time now) Cheers,Adrian [1] mod_auth_openidc RP lib seems to handle this 3rd party initiated login inhttps://github.com/zmartzone/mod_auth_openidc/blob/master/src/mod_auth_... sample OIDC RP would need to do something similar [2] Docs for okta dashboardhttps://support.okta.com/help/Documentation/Knowledge_Article/Th... https://support.okta.com/help/Documentation/Knowledge_Article/Using-the-A... De : Stian Thorgersen <sthorger(a)redhat.com&gt; À : Adrian Gonzalez <adr_gonzalez(a)yahoo.fr&gt; Cc : Keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; Envoyé le : Vendredi 16 mars 2018 13h50 Objet : Re: [keycloak-dev] KEYCLOAK-4509: OIDC IDP initiated login [Adding some info from the PR] OIDC IdP initiated login is something I assume there are specifications for already. So rather than doing a home-grown solution we should use that. There's some mention in OIDC specs about third-party initiated logins (https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiated...). I've not looked at it much, but it seems to cover this use-case. On 16 March 2018 at 09:24, Adrian Gonzalez <adr_gonzalez(a)yahoo.fr&gt; wrote: Hello, I would like to raise a thread on OIDC IDP initiated login (or OIDC third party initiated login). KC supports only SAML Clients for IDP Initiated login (http://www.keycloak.org/docs/ latest/server_admin/index. html#idp-initiated-login).When I have an OIDC app, I cannot use this feature.The need has been raised in KEYCLOAK-4509. I created an ugly PR to implement this feature, my use case is described in [1].In this implementation, I : - configured IDP initiated SAML between KC and external IDP- and hacked the code to test if the destination app was OIDC. If it was OIDC, then KC makes a plain redirect to the RP app (see also [1]).This allows SAML initiated IDP and conversion to OIDC app. We could implement that by relying on OIDC 3rd party initiated login.See  [3] on how this *could* work.This would allow OIDC third party initiated IDP for OIDC app (but this isn't enough for having SAML initiated IDP for an OIDC app - perhaps there's a solution for handling both OIDC 3rd party ). wdyt ? Cheers,Adrian [1] https://github.com/keycloak/ keycloak/pull/4965# issuecomment-373578277.[2] htt p://openid.net/specs/openid- connect-core-1_0.html# ThirdPartyInitiatedLogin[3] ht tps://github.com/keycloak/ keycloak/pull/4965# issuecomment-373580906[4] http s://issues.jboss.org/browse/ KEYCLOAK-4509   |  | Garanti sans virus. www.avg.com  | ______________________________ _________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/ mailman/listinfo/keycloak-dev