<commit_before>Enabling OAuth for Studio login
===============================

Migration guide for edx.org (and anyone else following master) in converting Studio login to use OAuth.

This is a temporary document for Arch-BOM.

Background
----------

As of Lilac, the Studio by default shares a session cookie with the LMS.  This either forces Studio to be on a subdomain of the LMS or the LMS to set its session cookie on a wide domain, which exposes it to a potentially large number of subdomains.

By setting up Studio to use LMS's OAuth2-based single-sign-on (SSO), the cookies (and domains) can be decoupled to improve both flexibility and security.

Migration
---------

Most of the configuration is already in place, and Studio and LMS just need to be configured in each environment to enable the new flow. (Devstack and sandboxes will autoconfigure for OAuth.)

Migration involves simultaneously enabling OAuth and separating the session cookies for LMS and Studio. This effectively causes a logout for Studio users, although they'll still be logged into LMS and aside from a brief disruption during the mixed-config interval they should not experience many problems.

For each deployed environment (stage, production, etc.):

#. Register an SSO OAuth2 client in LMS:

   - Add OAuth2 client:

     - Go to ``/admin/oauth2_provider/application/add/`` in LMS admin
     - Copy the prepopulated client ID and secret to a secure place
     - Leave the user field empty
     - Set redirect URLs to ``<STUDIO_ROOT_URL>/complete/edx-oauth2/`` (as well as for any additional domains, such as internally routed domains)
     - Set client type to ``Confidential``
     - Set authorization grant type to ``Authorization code``
     - Set the name to ``studio-sso``
     - Select the "Skip authorization" checkbox

   - Configure the client's scope:

     - Go to ``/admin/oauth_dispatch/applicationaccess/add/`` in LMS admin
     - Select application ``studio-sso``
     - Set scopes to ``user_id``

#. Configure LMS to log out Studio when logging out by adding ``<public Studio root>/logout/`` to the LMS ``IDA_LOGOUT_URI_LIST``.

#. Configure Studio to allow completion of OAuth flow::

    SOCIAL_AUTH_EDX_OAUTH2_KEY: <client id>
    SOCIAL_AUTH_EDX_OAUTH2_SECRET: <client secret>
    SOCIAL_AUTH_EDX_OAUTH2_URL_ROOT: <server-to-server LMS root URL>  # possibly same as public LMS root URL
    SOCIAL_AUTH_EDX_OAUTH2_PUBLIC_URL_ROOT: <public LMS root URL>

#. Configure Studio to initiative OAuth flow and use a separate session cookie::

    LOGIN_URL: /login/  # to activate OAuth functionality
    SESSION_COOKIE_NAME: studio_sessionid

Cleanup
-------

Config and code changes to be performed after all environments are using OAuth flow for Studio.

- Set ``LOGIN_URL`` to ``'/login/'`` in ``cms/envs/common.py``
- Deploy
- Remove ``LOGIN_URL`` overrides from all environments (devstack and others)
- Remove doc (convert to migration instructions for next release)

Declining the migration
-----------------------

Untested instructions for continuing to keep the shared sessions:

- Override ``FRONTEND_LOGOUT_URL`` for Studio to be ``<LMS base>/logout``
- Override ``FRONTEND_LOGIN_URL`` for Studio to be ``<LMS base>/login``
- Override ``LOGIN_URL`` for Studio to be ``<LMS base>/login``<commit_msg>doc: Update Studio OAuth migration guide for use in Maple release notes (#28784)<commit_after>Enabling OAuth for Studio login
===============================

This is a migration guide for converting Studio login to use OAuth, for use in the Lilac to Maple upgrade.

Background
----------

As of Lilac, the Studio by default shares a session cookie with the LMS.  This either forces Studio to be on a subdomain of the LMS or the LMS to set its session cookie on a wide domain, which exposes it to a potentially large number of subdomains.

Maple's configuration assumes that Studio will use LMS's OAuth2-based single-sign-on (SSO). This means that the cookies (and domains) can be decoupled to improve both flexibility and security. However, there are a few steps to take to finish this configuration (otherwise Studio logins will not work.)

Migration
---------

Studio and LMS need to be configured in each environment to enable the new flow, with the exception of devstack and sandboxes (which will autoconfigure for OAuth.) Migration involves enabling OAuth and separating the session cookies for LMS and Studio. The session cookie split will require Studio users to log in again.

Follow these steps for each deployed environment (stage, production, etc.):

#. Register an SSO OAuth2 client in LMS:

   - Add OAuth2 client:

     - Go to ``/admin/oauth2_provider/application/add/`` in LMS admin
     - Copy the prepopulated client ID and secret to a secure place
     - Leave the user field empty
     - Set redirect URLs to ``<STUDIO_ROOT_URL>/complete/edx-oauth2/`` (as well as for any alternate Studio domain names)
     - Set client type to ``Confidential``
     - Set authorization grant type to ``Authorization code``
     - Set the name to ``studio-sso`` or other name of your choice
     - Select the "Skip authorization" checkbox

   - Configure the client's scope:

     - Go to ``/admin/oauth_dispatch/applicationaccess/add/`` in LMS admin
     - Select application ``studio-sso``
     - Set scopes to ``user_id``

#. Configure LMS to log out Studio when logging out by adding ``<public Studio root>/logout/`` to the LMS ``IDA_LOGOUT_URI_LIST``.

#. Configure Studio to allow completion of OAuth flow::

    SOCIAL_AUTH_EDX_OAUTH2_KEY: <client id>
    SOCIAL_AUTH_EDX_OAUTH2_SECRET: <client secret>
    SOCIAL_AUTH_EDX_OAUTH2_URL_ROOT: <server-to-server LMS root URL>  # possibly same as public LMS root URL
    SOCIAL_AUTH_EDX_OAUTH2_PUBLIC_URL_ROOT: <public LMS root URL>

#. Configure Studio to initiate OAuth flow and use a separate session cookie::

    SESSION_COOKIE_NAME: studio_sessionid

This cookie renaming step is also a good opportunity to change ``SESSION_COOKIE_DOMAIN`` if desired, since it allows for a clean transition without having to worry about `flaky behavior driven by order-unstable cookie-sending <https://fwielstra.github.io/2017/03/13/fun-with-cookies-and-subdomains/>`_. Narrowing the domain (or removing it, to keep subdomains from seeing the cookie) may improve the security of your deployment, but the best option depends on the exact layout of your domain names and is beyond the scope of this document.
{'fraction_non_alphanumeric': 0.08326884383222412, 'fraction_numerical': 0.004798018882525925, 'mean_word_length': 3.914068441064639, 'pattern_counts': {'":': 0, '<': 19, '<?xml version=': 0, '>': 19, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4864545', 'n_tokens_mistral': 1815, 'n_tokens_neox': 1743, 'n_words': 841}