Support access token via environment variable instead of just client_credentials flow
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3582303. -->
Reported by: [mglaman](https://www.drupal.org/user/2416470)
Related to !819
>>>
<h3 id="overview">Overview</h3>
<p>The Canvas CLI currently requires OAuth <code>client_credentials</code> configuration<br>
(<code>CANVAS_CLIENT_ID</code>, <code>CANVAS_CLIENT_SECRET</code>, <code>CANVAS_SCOPE</code>) to obtain<br>
an access token for authentication.</p>
<p>Some sites may have authorization support beyond Simple OAuth and just need a specific bearer token passed along. Canvas CLI doesn't support these alternative authorization possibilities.</p>
<p>This issue proposes adding support for a <code>CANVAS_ACCESS_TOKEN</code> environment<br>
variable so that a pre-issued access token can be used directly by the Canvas CLI.</p>
<h3 id="proposed-resolution">Proposed resolution</h3>
<ul>
<li>
Add support for a <code>CANVAS_ACCESS_TOKEN</code> environment variable that, when<br>
set and non-empty, is used as a Bearer token for all Canvas API calls made by the CLI.
</li>
<li>
When <code>CANVAS_ACCESS_TOKEN</code> is set and non-empty:
<ul>
<li>The CLI uses it directly and does <strong>not</strong> perform the OAuth <code>client_credentials</code> flow.</li>
<li><code>CANVAS_CLIENT_ID</code>, <code>CANVAS_CLIENT_SECRET</code>, and <code>CANVAS_SCOPE</code> are ignored for that process execution.</li>
</ul>
</li>
<li>
When <code>CANVAS_ACCESS_TOKEN</code> is <strong>not</strong> set:
<ul>
<li>The CLI continues to use the existing <code>client_credentials</code>-based behavior with <code>CANVAS_CLIENT_ID</code>, <code>CANVAS_CLIENT_SECRET</code>, and optional <code>CANVAS_SCOPE</code>.</li>
</ul>
</li>
<li>
If <code>CANVAS_ACCESS_TOKEN</code> is set but empty or only whitespace:
<ul>
<li>The CLI fails early with a clear error message and does not silently fall back to <code>client_credentials</code>.</li>
</ul>
</li>
<li>
The value of <code>CANVAS_ACCESS_TOKEN</code> must never be logged (including in verbose/debug modes); logs may only indicate that an access token from the environment is being used.
</li>
</ul>
<h3 id="ui-changes">User interface changes</h3>
<ul>
<li>No user-facing UI changes.</li>
<li>Behavior change is limited to how the CLI obtains its access token based on environment variables.</li>
</ul>
issue