Change Details

### Background API access token management is messy. Today, the Action API must be used to fetch and manage required tokens, including CSRF and MediaWiki session management. OAuth may be managed through RESTful endpoints, but the specific endpoints are not easily discoverable. As we increase reliance on access tokens to better understand our users and enforce policies, it is critical that we make it clear for what is expected, and easy to follow the required workflows. ### Conditions of acceptance [] Clean up CSRF token management [] [[ https://phabricator.wikimedia.org/T392278 | REST Endpoint for fetching CSRF Tokens ]] [] [[ https://phabricator.wikimedia.org/T126257 | CSRF Tokens are not required when OAuth is used ]] [] [[ https://phabricator.wikimedia.org/T365513 | Improve CSRF Token handling in the REST API ]] [] REST endpoint exists for fetching and managing MW Session cookies [] Endpoints for fetching and managing OAuth tokens are clearly documented, discoverable, and usable [] Endpoints reflect any changes being made by MWP for OAuth refresh flows [] A dedicated API module is created for API token management [] Contained endpoints are fully documented and discoverable through the API Sandbox [] Spec passes linting [] Existing MW REST API specs are updated to utilize the "Security" object to describe available and expected access types. [] Token module and related docs are linked through "externalDocs" object

### Background API access token management is messy. Today, the Action API must be used to fetch and manage required tokens, including CSRF and MediaWiki session management. OAuth may be managed through RESTful endpoints, but the specific endpoints are not easily discoverable. As we increase reliance on access tokens to better understand our users and enforce policies, it is critical that we make it clear for what is expected, and easy to follow the required workflows. ### Conditions of acceptance [] Clean up CSRF token management [] [[ https://phabricator.wikimedia.org/T392278 | REST Endpoint for fetching CSRF Tokens ]] [] [[ https://phabricator.wikimedia.org/T126257 | CSRF Tokens are not required when OAuth is used ]] [] [[ https://phabricator.wikimedia.org/T365513 | Improve CSRF Token handling in the REST API ]] [] REST endpoint exists for fetching and managing all expected tokens [] Endpoints for fetching and managing OAuth tokens are clearly documented, discoverable, and usable [] Endpoints reflect any changes being made by MWP for OAuth refresh flows [] A dedicated API module is created for API token management [] Contained endpoints are fully documented and discoverable through the API Sandbox [] Spec passes linting [] Existing MW REST API specs are updated to describe available and expected access types. [] "security" object is used to outline the options for tokens [] "security" object is applied to relevant endpoints within the OpenAPI spec [] Token module and related docs are linked through "externalDocs" object

### Background API access token management is messy. Today, the Action API must be used to fetch and manage required tokens, including CSRF and MediaWiki session management. OAuth may be managed through RESTful endpoints, but the specific endpoints are not easily discoverable. As we increase reliance on access tokens to better understand our users and enforce policies, it is critical that we make it clear for what is expected, and easy to follow the required workflows. ### Conditions of acceptance [] Clean up CSRF token management [] [[ https://phabricator.wikimedia.org/T392278 | REST Endpoint for fetching CSRF Tokens ]] [] [[ https://phabricator.wikimedia.org/T126257 | CSRF Tokens are not required when OAuth is used ]] [] [[ https://phabricator.wikimedia.org/T365513 | Improve CSRF Token handling in the REST API ]] [] REST endpoint exists for fetching and managing MW Session cookiesall expected tokens [] Endpoints for fetching and managing OAuth tokens are clearly documented, discoverable, and usable [] Endpoints reflect any changes being made by MWP for OAuth refresh flows [] A dedicated API module is created for API token management [] Contained endpoints are fully documented and discoverable through the API Sandbox [] Spec passes linting [] Existing MW REST API specs are updated to utilize the "Security" object to describe available and expected access types.describe available and expected access types. [] "security" object is used to outline the options for tokens [] "security" object is applied to relevant endpoints within the OpenAPI spec [] Token module and related docs are linked through "externalDocs" object