# Multiple apps in the same portal **URL:** \ **Category:** SAML\ **Created:** [July 19, 2018, 4:12pm UTC](https://devforum.okta.com/t/multiple-apps-in-the-same-portal/2207 "2018-07-19T16:12:45Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [July 25, 2018, 10:37pm UTC](https://devforum.okta.com/t/multiple-apps-in-the-same-portal/2207/3 "2018-07-25T22:37:12Z")
I assume all your SPA apps use the same logic that takes a user to Okta’s login widget. When a user has logged in to Okta from one app, Okta will store a session cookie for that user in the browser. When the user navigates to another one of your apps, since it’s the same browser, the Okta cookie will be sent to Okta by the browser, and OKta login widget will not need to show, since the cookie proved the user has logged in recently. Your second app should/would silently let the user pass authentication since Okta let it pass. The part about Okta cookie is similar to the other question by the following link, although I understood yours are SPA apps, and the apps in the other question likely use authentication middleware on the server side. But still, the Okta cookie usages are the same. > [@How is session cookie used to enable SSO?](https://devforum.okta.com/t/how-is-session-cookie-used-to-enable-sso/2184/2): > > Since you mentioned creating cookies, I assume app A & B both use the same server-side logic (perhaps middlewares since it’s a common practice) to make sure users are authenticated before they can access protected resources of your apps. When your app uses middleware, there would be a cookie middleware on top of an authentication middleware. The cookie middleware processes the request first. When it sees a valid session cookie issued by your app before, authentication criterion is met, and the … --- _[View the full topic](https://devforum.okta.com/t/multiple-apps-in-the-same-portal/2207)._