# Deprecation/Removal: Complete removal of Studio signin and signup pages (relates to DEPR-6) **URL:** \ **Category:** Deprecation\ **Created:** [December 4, 2019, 7:44am UTC](https://discuss.openedx.org/t/deprecation-removal-complete-removal-of-studio-signin-and-signup-pages-relates-to-depr-6/962 "2019-12-04T07:44:36Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![robrap](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/robrap/32/721_2.png) [@robrap](https://discuss.openedx.org/u/robrap)\ **Post date:** [December 4, 2019, 7:44am UTC](https://discuss.openedx.org/t/deprecation-removal-complete-removal-of-studio-signin-and-signup-pages-relates-to-depr-6/962/1 "2019-12-04T07:44:36Z")
The PR [#22416](https://github.com/edx/edx-platform/pull/22416) completes the work started in [#19453](https://github.com/edx/edx-platform/pull/19453) to use the LMS login and registration for Studio, rather than Studio providing its own implementation. LMS login and registration are being used for the following reasons: 1. LMS logistration properly handles all SSO integrations. 2. A single logistration is simpler to maintain and understand. 3. Allows Studio to work more like all other IDAs that use LMS logistration. The original switch to use LMS logistration for Studio also added the toggle `DISABLE_STUDIO_SSO_OVER_LMS` to provide the community some additional time for switching. This temporary toggle is being removed, which at this point means all deployments will use the LMS logistration. This change requires sharing cookies across LMS and Studio. Should that prove to be a problem for certain Open edX instances, there are notes of possible alternative solutions. See [#19845 (comment)](https://github.com/edx/edx-platform/pull/19845#issuecomment-559154256). Feel free to continue the discussion in this topic. This work relates to: - [ARCH-218](https://openedx.atlassian.net/browse/ARCH-218) - [DEPR-6](https://openedx.atlassian.net/browse/DEPR-6) [ARCH-1253](https://openedx.atlassian.net/browse/) ---
**Author:** ![regis](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/regis/32/2640_2.png) [@regis](https://discuss.openedx.org/u/regis)\ **Post date:** [December 4, 2019, 9:14pm UTC](https://discuss.openedx.org/t/deprecation-removal-complete-removal-of-studio-signin-and-signup-pages-relates-to-depr-6/962/2 "2019-12-04T21:14:45Z")
> [@robrap](#): > > This change requires sharing cookies across LMS and Studio. Why is that the case? This is not how SSO usually works, is it? I think it’s a shame that the studio and the LMS have to share a common domain name. It seems like an unnecessary constraint on platform deployment. Are there other components of the LMS/CMS that require that the CMS reside at a subdomain of the LMS? ---
**Author:** ![robrap](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/robrap/32/721_2.png) [@robrap](https://discuss.openedx.org/u/robrap)\ **Post date:** [December 4, 2019, 10:30pm UTC](https://discuss.openedx.org/t/deprecation-removal-complete-removal-of-studio-signin-and-signup-pages-relates-to-depr-6/962/3 "2019-12-04T22:30:54Z")
I imagine it is because it was a simple solution that got us to a shared login page given CMS is part of edx-platform with a shared database. @Felipe noted the following possible alternatives on one of the PRs: - convert the studio auth into a real SSO third party authentication using Oauth2 - use the plugins mechanism to create authentication view for studio (can be done independently by the community. No need to merge anything to the core) Either of these could be pursued. It is unclear whether the oauth2 solution we use with the other IDAs will play nicely with the fact that the users already exist in the db. We also have similar constraints around subdomains with the JWT cookies and our new microfrontends for now.