@bressler1995
As @jerry_nguyen wrote, when you are accessing Canvas through a browser, the cookie contains authorization information. Open up the developer tools in your browser and switch to the network tab. Pick a request and you'll see a Cookie in the request headers.
There is a _csrf_token, usually towards the end, which is your authorization token. There will also be one in the cookie response header.
Because that is part of a cookie, the browser sends it with any request from its domain. In fact, you can open a new browser tab, make an API request, and it will send the token with the request will work. Go ahead and try it with something like https://<instance>/api/v1/users/self and you should get JSON about your user account.
That means that you can embed JavaScript (globally with the custom JavaScript under theming or locally using a userscript manager like Tampermonkey) and you can make GET calls to the API from within your code.
As for Canvas not documenting it. It is as reliable as anything custom with Canvas. It works until it doesn't. Don't let that scare you. They are extremely unlikely to change this. They warn you that any of the custom JavaScript you needs to be tested and you have to pay attention to changes and monitor your beta instance to make sure it doesn't break.
That said, Canvas likely won't change the authentication portion. There has been talk of deprecating third-party cookies and some browsers block those by default. This token is within a first-party cookie and your JavaScript will be running within Canvas so it will allowed to access it.
This works for any GET request. If you want to do a PUT or POST, you need to send the _csrf_token with the request. You don't send it as _csrf_token, though, you have to set authenticity_token to the value of the _csrf_token that Canvas sent in the response header. I run it through decodeURIComponent before using it. Again, this is not necessary for a GET request.
When you make an API call from within JavaScript loaded inside Canvas, do not include an authorization header in the request. That would require a regular token that was generated and it would be extremely bad to include that in your JavaScript code that anyone can look at. Let the cookies handle things for you when you're running code from within Canvas. If you're running code outside the browser, then you need a token and authorization header.
While Jerry mentioned that most calls are made through the API, there are some internal, non-API calls, as well. In those instances, the JavaScript that you load through the theme or a userscript will still work. This allowed me to write code to get the access report data for an entire class when a non-API call was the only way to do it. The mobile app didn't have that feature and it never got converted into an API.
If you're looking for publicly documented features, then the API is safer. Those non-documented calls exist, but could change without notice. In the 13 years I've been using Canvas, that rarely happens. Any changes often come as part of an upgrade, such as the Enhanced Rubrics or part of their push to move more things to use Instructure UI and get away from jQuery.