We have a SPA that uses okta-auth js SDK to authenticate users. Now we wanted to implement a use case where the external IDP users will be able to access our application using Okta’s Inbound Federation.
To implement the same do we have idpDiscovery and features object properties present in okta auth js SDK, which are needed while configuring the application?
I was able to implement the same flow with the Okta sample app which was using the okta-sign-in widget SDK and those properties were part of it and were require to complete the flow.
To complete the federated login, the Sign In Widget calls the webfinger endpoint, sending the username to determine which Identity Provider the user is associated with.
When using Auth JS, you can make this same API call using webfinger(options). In the response to this call, you will get the IdP ID back, which you can then include it as a parameter in your /authorize request as part of the options. That will result in the user getting redirected directly to their IdP and then back to your OIDC application (with the auth code/tokens) via the redirect_uri once they’re logged in.
When trying to hit the Webfinger endpoint, using the following cURL
curl --location --request GET 'https://dev-94069277.okta.com/.well-known/webfinger?resource=okta:acct:finaltest%40z-mail.io' \
--header 'Accept: application/jrd+json' \
--header 'Content-Type: application/json' \'
This is the response that we get
Did not find the idpID in the response. And also getting the same response when using some non-existing user as well.
FYI: The user passed in the request (finaltest@z-mail) was created by JIT during the federated login.
The external SAML IDP is configured in this domain (http://dev-94069277.okta.com) and the routing rule is also defined for the user’s domain (z-mail.io)
Can you try without encoding the
@ symbol? What if you remove the domain and just make the request with
Same response even without the domain
It looks like in this instance, the “finaltest” account matching IdP is actually the Okta instance itself. I suspect that this user is hitting the default rule. In that case, I would check to make sure your routing rule’s condition is configured to match the “finaltest” user to their corresponding federated IdP.
I have two okta instances where one instance ( dev-94 ) can be considered as OUR IDP and acts as the IDP for the sample application to which we want the external users to give access and the other okta instance (dev-15 ) acts as the external IDP from which the users will be redirected from the SAML app configured in it back to the sample app through IDP initiated federated login and that user will be created in the OUR IDP through JIT.
The above flows work fine when used with a sample app using Okta-Sign-In Widget. But not able to implement the same flow with other sample application which uses Okta Auth SDK.
FYI: IDP configuration and routing rules (with domain rule ) are configured correctly in the dev-94 instance and when tried to hit the Webfinger API with a user that is created through JIT not able to get the IDP ID.
Does the external IDP has to be some IDP other than Okta inorder to use webfinger? or passing rel parameter as part of request helps ?