# Can't get a session with oidc-middleware

**URL:** <https://devforum.okta.com/t/cant-get-a-session-with-oidc-middleware/3591>\
**Category:** OAuth/OIDC\
**Created:** [December 8, 2018, 12:11am UTC](https://devforum.okta.com/t/cant-get-a-session-with-oidc-middleware/3591 "2018-12-08T00:11:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dima](https://avatars.discourse-cdn.com/v4/letter/d/e47c2d/32.png) [@dima](https://devforum.okta.com/u/dima)\
**Post date:** [December 8, 2018, 12:11am UTC](https://devforum.okta.com/t/cant-get-a-session-with-oidc-middleware/3591/1 "2018-12-08T00:11:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dima](https://avatars.discourse-cdn.com/v4/letter/d/e47c2d/32.png) [@dima](https://devforum.okta.com/u/dima)\
**Post date:** [December 13, 2018, 12:49pm UTC](https://devforum.okta.com/t/cant-get-a-session-with-oidc-middleware/3591/2 "2018-12-13T12:49:16Z")

</div>

Is there anyone around that can take a look at the issue?  
Any suggestion to make the existing flow work, and/or alternative one, would be greatly appreciated.

Dima.

---

<div class="post-metadata">

**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\
**Post date:** [January 13, 2024, 12:13am UTC](https://devforum.okta.com/t/cant-get-a-session-with-oidc-middleware/3591/3 "2024-01-13T00:13:23Z")

</div>


