[breton]

> I guess I'm most confused about where the connection between Ory and the application server is.

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.

[tinco]

Just to clarify, as not everyone is familiar with service based architecture: When the application server is air-gapped from the identity provider, it is meant that your frontend application will have user information embedded in the requests it makes.

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.

[d_watt]

I know this is the discussion as old as JWTs, but the tradeoff here is how do deauthenticate the user. If you delete/disable the user, or change their role, there's still a stateful JWT out there claiming they have certain grants.

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).

[emurlin]

That'd depend on the implementation details. Within the Ory ecosystem, you have Kratos (identity management), Hydra (OAuth2 & OIDC server, dealing mostly with token issuance, not so much with identities, which you have to provide externally) and Oathkeeper (API gateway).

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.