
i2kyi (i2kyi) asked a question.
Dear Community
We are in the process of incorporating Okta SSO into our application in order to allow some of our clients that are already Okta organizations to permit their users to sign into our application by means of their Okta credentials.
The guides are quite comprehensive except for one point that I cannot seem to nail down and it would be great if anybody could shed some light on the matter for me please.
After us successfully submitting our application to Okta for review to be made available via the OIN, it would be possible for the Okta account administrators within our common client organizations to find our app and provide access to users and/or directories within their admin console.
However the flow interaction is what remains unclear to me, would these provisioned users then going forward always have to first visit their Okta dashboards and then launch our application from there? Or is there a flow similar to what is illustrated within the majority of the SPA quickstart guides as far as I can see where the user could potentially first hit our site and then click on some kind of link taking them to the Okta sign in page that then redirects them back to our site in the case of successfully authenticating?
The point that makes me think the auth redirect flow does not make sense in the case of OIN applications is that the client application takes the users wanting to sign in with their Okta credentials to a client-app side configured issuer Okta organization url (referred to as the issuer) and I suspect that also provides the context for the Okta organization within which the user will be authenticating and therefore cannot be the url for our Okta organization as the authenticating user is actually signing on to our client's Okta organization.
Your assistance in this regard would be greatly appreciated!

Hello @i2kyi (i2kyi)
I hope you are having a great day
Thank you for posting, There are two different sign-in flows for which authentication can be handled by SAML. The first method, known as an SP-initiated flow, occurs when the user attempts to sign onto a SAML-enabled SP via its login page or mobile application (for example, the Box application on an iPhone). Instead of prompting the user to enter a password, an SP that has been configured to use SAML will redirect the user to Okta. Okta will then handle the authentication either by prompting the user to log into Okta, or via Desktop Single Sign On (DSSO). If the user’s credentials are correct and the user has been granted access to the application on the Okta side, they will be redirected back to the SP as a verified user.
The second flow is known as an IdP-initiated flow. This occurs when the user logs into Okta (or launches Okta Mobile) and launches the SP application by clicking its chiclet from their Okta home page. If the user has an account on the SP side, they will be authenticated as a user of the application and will generally be delivered to its default landing page (their actual destination within the SP's site is customizable). If they do NOT currently have an account on the SP side, in some cases SAML can actually create the user's account immediately in a process known as Just In Time Provisioning (JIT - please consult our Provisioning Guide for more details)
I hope this helps!!!
Regards
Henry E.
Okta Inc