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