Authorization

You can also authorize other existing orgs, such as sandbox or packaging orgs, to provide more flexibility when using CLI commands. For example, after developing and testing an application using scratch orgs, you can deploy the changes to a centralized sandbox. Or, you can export a subset of data from an existing production org and import it into a scratch org for testing purposes.

You authorize an org only once. To switch between orgs during development, specify your username for the org. Use either the --targetusername (or --targetdevhubusername) CLI command parameter, set a default username, or use an alias.

You have some options when configuring authorization depending on what you’re trying to accomplish.

• We provide the OAuth 2.0 web server flow through a global out-of-the-box connected app. This authorization flow implements the OAuth 2.0 authorization code grant type. With this flow, the server hosting the web app must be able to protect the connected app’s identity, defined by the client ID and client secret. When you authorize an org from the command line, you enter your credentials and authorize the global connected app through the Salesforce web server authorization flow. See OAuth 2.0 Web Server Flow for Web App Integration.
• For continuous integration or automated environments in which you don’t want to manually enter credentials, use the OAuth 2.0 JSON Web Tokens (JWT) bearer flow. This flow is ideal for scenarios where you can’t interactively log in to a browser, such as a continuous integration script. However, this flow does require prior approval of the client app. See OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration.