There is no such thing as non-resource data. You can model pretty much everything in terms of resources.
Those resources do not have to map directly to tables or even exist as identifiable entities in your persistence layer. From an api consumer's perspective it is mostly irrelevant whether or not the resource representation is an actual database row or document or a entirely abstract entity conjured on demand.
Implementing Abstract resources using JR is straightforward and is supported out of the box:
Abstract Resources
Resources that are not backed by a model (purely used as base classes
for other resources) should be declared as abstract.
Because abstract resources do not expect to be backed by a model, they
won't attempt to discover the model class or any of its relationships.
Now, coming back to your use cases:
This can be modelled as an AuthToken resource (with a single attribute) that is related to (many-to-one association) a User resource. And in your case it may happen that your user resource is included along with the AuthToken resource in the same API response.
Again, if you model your entire domain around resources, any and all actions can be modelled as CRUD actions. Login is just creation of a UserSession resource.
JSON:API specification allows inclusion of related resources:
Inclusion of Related Resources
An endpoint MAY return resources related to the primary data by
default.
An endpoint MAY also support an include request parameter to allow the
client to customize which related resources should be returned.
And this feature is fully supported by JR as well.