That action takes a short lived token with the purpose of “sign_in” and exchanges it for a long lived token that is good for the standard duration.
This exists due to the implementation of liveview. The log in views are liveviews and a liveview cannot put anything into the session except on page load (at least not when we built it, although maybe something could be done with hooks, not sure) and we wanted to support immediate feedback when you submit the form. So the liveview calls the sign in with password action which validates your credentials on the spot. If they are wrong you get a standard form error, if they are right you get redirected to an endpoint with your short lived sign in token to exchange for a long lived token that gets put in the session. Because the LV couldn’t modify the session, and we don’t want to send the username and password in a redirect (we cannot it would be insecure) a sign in token was the only way to be secure while having the UX we wanted.
To get a short lived sign in token that can be used with that endpoint, you’d need to set this context:
In terms of “where can you read about” the docs are on hexdocs. If what you’re looking for isn’t there then it isn’t anywhere. However, it can be easy to miss the DSL docs. Scroll down and look in the bottom of the sidebar, which has docs for every option.
What specifically are you trying to do/implement? It’s possible there is some X/Y problem going on here. You’re asking about sign in tokens but they are for a single purpose which is signing in over a liveview.
Folks have implemented their own token refresh system on top of ash authentication’s token it just isn’t built in yet, so that is very much an option 
Perhaps ask in the discord to see if someone can share their implementation? If they do, ask them to share it here so others can find it.
