3 ms·

As someone who knows very little about serious identity management, does something like Ory handle the auth part (in a variety of schemes), and then your applic

by jjice 4y ago

As someone who knows very little about serious identity management, does something like Ory handle the auth part (in a variety of schemes), and then your application interacts with Ory somehow to validate the auth? I guess I'm most confused about where the connection between Ory and the application server is. 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!

breton 4y ago
> 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 4y ago
  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 4y ago
    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 4y ago
      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.
deleted 4y ago
[deleted]
alextheparrot 4y ago
The main idea is that instead of a session cookie you are usually exchanging signed information in this scheme. Your app server or an intermediate proxy validates that the signing was authentic, and then receives some information (Often called “claims”) — such as “This account is an admin role user”, or “This account has user id 1234”. 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)!

by jjice 4y ago

breton 4y ago

> 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 4y ago
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 4y ago
  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 4y ago
    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.

deleted 4y ago

[deleted]

alextheparrot 4y ago

The main idea is that instead of a session cookie you are usually exchanging signed information in this scheme. Your app server or an intermediate proxy validates that the signing was authentic, and then receives some information (Often called “claims”) — such as “This account is an admin role user”, or “This account has user id 1234”. 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)!