I've only ever dealt with auth a monolith with sessions, so I'm pretty blind here.
Any resource anyone would recommend would also be greatly appreciated!
With those pieces of information, you can do all your application lookups securely. With a bit of middleware to handle the incoming signed data (Often JWT), it probably looks about the same as your session-based authentication. The only difference is that you’ve split out and centralized your authentication (And possibly authorization via claims)!
There might be none. The response from an identity provider (Ory) is signed and encrypted, is given to the user who is being authenticated and then the user brings it to the application. The process usually happens via browser redirects, but can be more manual. The response contains information about who the user is, their identifiers and properties. It is totally possible to have a scenario where the application is air-gapped.
There might be some interaction if the application wants to enrich the passed response.
I cannot suggest any books, but you could search about SAML2, OpenID Connect (oidc), identity providers and service providers.
For example by setting a JWT in the headers or in a cookie when it's a web application.
Even the responsibility of validating that information can be extracted from the application server by doing that in the application gateway (also known as the ingress, for example nginx) which can be configured to read the JWT (or whatever format you choose) and reject unauthenticated/tampered requests.
You either need to accept a certain TTL on the JWT, or be able to revalidate the JWT on every request with some authoritative service to ensure the grants are good (which sort of invalidates the value of the grants encoded in the JWT itself).
For browser use cases, the recommended approach with Kratos is to use cookies (which means that Kratos need to follow the same site rules for the site it's set up for). Since Kratos is separate from the system you're trying to provide authentication for, you need some kind of token issuance, but you can make it as short-lived as you'd like. Within the ecosystem, you'd use Oathkeeper to transparently convert a Kratos cookie to an ID token, but this token can be generated with an arbitrarily short lifespan, and so you can revoke sessions with immediate or almost immediate effect.
Where things get a bit more complicated are if you exchanged that 'local' Kratos token for a different sort of token, like an OAuth2 bearer token (which may give access to external systems). In this case, ending the Kratos session doesn't immediately revoke those other tokens. You need to either accept that tokens might outlive the actual session they originated from (sometimes you might even _want_ this, for instance in an asynchronous service), or else keep track of these other tokens and revoke them individually.
If you're using Hydra for these other tokens, you can either use JWT or 'opaque' tokens. With JWT, you have the issue you mention that the token itself has some state that might become stale, but if you're using 'opaque' tokens, you don't get any claims from the token itself and you're supposed to get these from a separate introspection endpoint. You can make these introspection requests as often as you'd want, like for Kratos cookies above. Hence, if you revoke the session in Hydra (or whichever other OAuth2 server you're using) and you're validating tokens, you can revoke sessions almost immediately, with some overhead that comes with splitting a system into separate ones.