Correct behavior of Initiate login URI ( implicit/callback )


Could you please help me understand expected behavior of ‘Initiate login URI’ ( implicit/callback ). Should ‘Initiate login URI’ redirect to somewhere or not?

React app with “@okta/okta-auth-js”: “5.1.1”, “@okta/okta-react”: “6.0.0”, react-router-dom

When a user presses app tile on Okta dashboard (the same as App Embed Link) then okta redirects to ‘Initiate login URI’ + ? (in my case http://localhost:8085/implicit/callback? ). And app does nothing, just shows blank screen.

I tried different options, but most of them are add route to react route

                <Security oktaAuth={oktaAuth} restoreOriginalUri={restoreOriginalUri}>
                        <Route path='/implicit/callback'  component={LoginCallback} />

I expected ‘Initiate login URI’ should redirect (launch restoreOriginalUri) to app route, but it looks like LoginCallback does not do it. In this case, how should be handled ‘Initiate login URI’ (in my case http://localhost:8085/implicit/callback? ) in react app?

PS: /login/callback’ works fine (redirects), when a user tries to use direct app url using <Route path={CALLBACK_PATH} component={LoginCallback} />.

Okta will redirect users to the Initiate Login URI for your app if 1) your app is set to use the “OIDC Compliant” Login flow, 2) the user launches your application in their end-user dashboard (you would need to update your app to be visible to users), or 3) user is redirected to Okta via the App Embed Link

What you are seeing is expected behavior: when the user clicks on that dashboard tile or uses the app embed link, they will be redirected to your app via the ‘initiate login uri’ set and the only thing that will be passed back to your app is a query parameter indicating which Okta tenant they came from.

When using the OIDC compliant login flow, you will need to initiate the OAuth flow from your application instead, as OIDC itself only supports sp-initiated flows, where the application makes the request for tokens.

One way to do this is to attempt to detect a users existing Okta session when they reach your initiate login URI:

Given you are making a SPA, I would recommend that you NOT set this URI to your callback route and instead route users to your main login route. That way all of this session/authentication related logic happens on one route and you do not have anything else on your callback route that is not about handling a token returned to it.

Hi Andrea, thanks for the reply.
What do need to be fixed in result below:

I’ve tried to route users to your main login route:

I still getting blank page with address if user logged in and uses App Embed Link:
In react router:
<Route path='/login/callback' component={LoginCallback} />
What is incorrect in this case?

What about if you set it to your app root instead, http://localhost:8085?

I tried, it’s a bit better:
but still show some unnecessary data ‘?’ whereas if I go directly to url and it redirects to Okta for auth and back to app, it does not do it.

We will always include that ‘iss’ query parameter when redirecting to your application from the Okta dashboard.

Question is, does the application work correctly for the user when they are redirected? Like I mentioned in my previous post, unless you have some SSO logic in place, these users will not have tokens until your application initiates the OAuth flow

Yes application works correctly, but for and App Embed Link (tile) ‘iss’ works differently.

  1. If a user authenticated in Okta and runs the app first time on this machine => no ‘iss’
  2. If a user authenticated in Okta and runs the app second time => ‘iss’ exists

I believe, when the browser does not know about the app (does not have okta tokens for the app cookes/local storage and etc) => it runs restoreOriginalUri and during redirectings (including redirect to login/callback ) ‘iss’ disappears.
All other times when browser knows about the app ( have okta tokens for the app cookes/local storage and etc) restoreOriginalUri will not be launched => ‘iss’ persists.