It's my (possibly flawed) understanding that the authorisation code grant is attractive because it keeps access tokens away from a potentially insecure user agent.  I understand how this would work with the initial call:

- The (insecure) user agent gets a code from the auth server
- The agent then hands the code to the (secure) client application.
- The client application can then exchange it for access/id/refresh tokens.

All good so far.  But now the user agent makes a 2nd request.  How does that request get linked with the token(s) from the initial call?

 - It could go back and get another auth code, but this seems
   impractical.
 - It can't use the same code again as they're single use.
 - It doesn't have any of the tokens itself (as they're nice and safe on
   our app server).
 - So that leaves me with sessions.  I.e. The app
   server matches the HTTP session with the tokens.

Can someone confirm or correct this assumption?  While the initial call is well documented, I can't find much in the way of what happens on subsequent calls.  Any links to the actual mechanism would be appreciated!

**Edit (to add context)**

I am interested in securing a single page application calling an API.  In the past I used an implicit grant for such interactions (with the access token being sent from the browser on every API call).  However, given that the [implicit grant is no longer consider to be secure][1] I would like to switch to an authorization code grant.

So my question is:  After the initial authentication, what goes out on each subsequent API call for authentication?

- A token?
- A session cookie?
- Something else?

  [1]: https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926