Hi,
We’re working with the oidc-middleware package on NodeJS and are trying to add support for an “Okta SSO” scenario, to support customers whose organization is already using Okta, so they can sign in once and use that authentication to sign them in to our web app (and have a valid session). Here’s the flow:
A user receives an invite email to sign in to our web app. Upon clicking the invite button in the email, a request is sent to our server, generating an html page that has a form with a single submit button: “Sign in with Okta”.
Clicking the “Sign in with Okta” button will send a POST request to our server (includes the user’s email), to a dedicated route (e.g. /okta_signin) and at this point we generate a redirect link for the user’s organizational Okta, e.g. (on my local setup) -
const oktaRedirectLink = https://<application>.oktapreview.com/oauth2/v1/authorize?&client_id=<clientId>&response_type=token&scope=email%20profile%20openid&redirect_uri=http://localhost:8080/login&nonce=e486e830-b894-48c2-b73a-8d23d160adc6&state=OKTA:18984f4f-c2d1-4e5d-9368-3fd80c3bc3df&_csrf=DI1MqlKO-q92DKwfc_nen53C27hoUOJ_G1pU;
The next line of code returns a response that redirects the request from our server to this link so the user can sign in with his username/password directly to his organizational Okta:
return res.redirect(302, oktaRedirectLink);
Once the user signs in to his organizational Okta (successfully), he is redirected by Okta back to the specified redirect_uri on our server.
Now, despite the fact that the user is authenticated by his organizational Okta (i.e. we do get an access_token and state as part of the redirected response when the response type is token, or a code param), the request doesn’t seem to get validated locally and a session isn’t created.
I tried with both response_type=token and response_type=code, and tried changing the redirect_uri route to /authorization-code/callback that is handled by the oidc-middleware.
I assume that it has to do with the fact that our custom route (/okta_signin) is not one of the routes defined directly on the oidc-middleware (the default ones in our case - GET /login & POST /authorization-code/callback), so the state param sent as part of the v1/authorize request to the external Okta is not being ‘tracked’ and can’t be verified when successful response does come in.
What should we do to have the oidc-middleware aware of this “external Okta” authorize request, and have it validate and create a proper session for this use case?
Any help is appreciated, we’ve been trying to overcome this issue for several days now…
Dima.