Initate Login URI from SSO provider
Hello, I have a client who is integrating with us using their okta oidc client. For the most part everything is working well, but we want to enable the ability for their okta client to initiate the login process rather than relying on the login button from our login page to their specific okta client. Okta supports this easily enough, but it has a
Initate Login URI configuration variable that I don't know what to tell them to put in. For reference, when specified and the client then tries to start the login, they are redirected to the configured URI with an iss search param that refers back to the cleints SSO provider. I assume at that point the app just needs to redirect to that issuer the same way the redirection happens if the user were to click the SSO button on our login page.
I've attached a picture of the configration options within Okta.
11 Replies
cc @Matías @Federico
hi @Ty thanks for your question, I have tagged engineers in my team who will take this from here. Thanks
Hi @Ty 👋 the
Initiate login URI in the Okta application should point to an endpoint in your application. When Okta redirects to this endpoint, it should trigger a request to Zitadel's authorize endpoint using the urn:zitadel:iam:org:idp:id:{idp_id} scope so the user will directly be redirected to the identity provider -Okta- to authenticate. I hope that helps! Please let us know if you have any other questions.That is super helpful. Thank you!
Got that working, thanks again.
One thing I might ask for is a way to query for an identityProvider based on the issuer. All I'm seeing in the API docs is the ability to query for it on ID, or fetch a list of providers from the settings api, the list does not include the issuer value though. So I'm faced with the prospect of fetching every provider each time an external login is started this way, or configuring issuer -> idp.id in our codebase someway. The option we actually went with is to set the name value of our idps to match the issuer, since the name is in the list returned from settings, that works well enough, but feels a bit hacky.
Hey @Ty ! As you probably know, we are migrating to a resource-based API approach (API V2), but until we have feature parity, you might need to use the existing service-based AIPs for now. There is an endpoint to list identity providers in V1, and you can add an
idpNameQuery parameter:
https://zitadel.com/docs/apis/resources/admin/admin-service-list-providersZITADEL Docs
Returns a list of identity providers (social/enterprise login) configured on an instance level. e.g Google, AzureAD, etc.
I missed that, that is better. Thank you!
Sorry to keep bugging on this, tell me if I should open another ticket, but now that I have gone through the local dev process successfully, I am testing this out on a deployed / hosted instance and hitting a new issue that is kind of baffling me. Going through the SSO login flow, at the very end it appears that the zitadel client is redirecting back to
localhost:3000 rather than our custom login URL? I am attaching a network log of our redirects, and it looks like it is going from our hosted zitadel instance back to localhost:3000/idp/oidc/success which does correlate to a path in our hosted login (a near copy of the login app at https://github.com/zitadel/typescript) but obviously it should be going back to the login app at https://auth-staging.hustle.com, which you can see it actually does start the process at. I've been picking through settings and documentation and I'm a bit at a loss for where this localhost redirect is coming from.These are all staging credentials that don't actually grant access to real data so I don't mind sharing these tokens.
Ok, took awhile, but I finally got to the bottom of it. It's from this line here: https://github.com/zitadel/typescript/blob/6c7fa7308d081ed8f0fbec771740043cb6ccd016/apps/login/src/app/login/route.ts#L189
GitHub
typescript/apps/login/src/app/login/route.ts at 6c7fa7308d081ed8f0f...
Typescript packages and application to showcase the ZITADEL resource API - zitadel/typescript
The nextUrl.origin was always specified to be
localhost:3000 despite where the next app was actually being hosted. Not sure where to configure that but we're just going to override it with an env var instead.GitHub
[Bug]: SSO Redirects Always Returning to localhost:3000 · Issue #4...
Preflight Checklist I could not find a solution in the documentation, the existing issues or discussions I have joined the ZITADEL chat Version No response Describe the problem caused by this bug W...
Hi @Ty, thanks for creating that issue, and I apologize for the late reply, it was a long weekend here. I'm glad to see that you were able to find a solution 🙌
No worries, thanks for all the help!