This message was deleted.

We have actually been trying to solve this for a while! Our specific usecase required that the identity tied to the api key was not a user, but instead a service user, so if that doesn’t apply to you there may be a few other ways to achieve api keys based on just Kratos. A few solutions include: • Separate identity schemas for service users • Separate instances of kratos for service users, using the username and passwords of the identities as basic auth credentials, or writing middleware that splits an api key on a given delimiter which is then used as the username/password in a login flow • Having your reverse proxy configured to forward auth requests (Caddy

forward_auth

, nginx

subrequest

, etc.) to both Kratos and an API key service, or potentially as an authoriser in Oathkeeper • Use Ory Hydra’s client credentials • Create a custom service to handle api keys separately to Kratos There is also a blog post that touches on how you can use Kong’s api key plugin paired with Oathkeeper and Kratos to add api keys to your auth stack https://www.ory.sh/zero-trust-api-security-ory-tutorial/ A similar configuration to the reverse proxy stuff can be seen in this Ory Summit video too! This isn’t trivial though, we have gone through much research to come up with a solution that woks for us! Also worth noting that we use gRPC/gRPC-Web, which I believe isn’t supported by Oathkeeper, so this made things a little more complicated for us!

Thanks - this is helpful, and I’m glad it wasn’t obvious for my own sake!

We went down the custom service route, though a different one to what you are proposing. I think to truly cover your usecase without being confined to limitations of 3rd party systems, this might be the most straight forward solution. But I would explore the others first as there might be some out-the-box solution that works! If you could keep me posted on how things go that would be amazing, as we’re still learning how we can optimise this! I am open to DMs! 🙏

Awesome - me too. Sounds good. One final thought before the weekend: I wonder if in my case we could make use of the conceptual split between authentication and authorisation, and have said tiny PAM service do authentication, and then a more standard approach to authorisation.

If I understand that correctly, I think this is essentially how the reverse proxy auth forward and/or Oathkeeper setup would work. You would proxy your boxes through a reverse proxy that forwards the request on to an auth service, which can then inject the relevant auth headers from the forwarded auth response into the proxied request. Those are then used to make Ory Keto authorisation checks. If your system does not rely on RPC (i.e. you are using standard HTTP/REST requests) I think Oathkeeper is super powerful for writing these rules. All of this is just spitballing, so take all of this with a pinch of salt!

Hmm. Yes, that’s true. If we used oathkeeper with client credentials, and made a PAM authenticator, then that would work rather nicely

This is extremely interesting, thanks for discussing this here. @microscopic-forest-58980 @freezing-solstice-24704 A question though, been also thinking about multiple schemas for service accounts, but I can't figure out how to make them work with the flows. As in, a service account shouldn't be able to log into my UI. Or it shouldn't be password recoverable. Is this up to me to gate?

It might be worth moving this convo over to the Ory Keto discussions over at https://github.com/ory/kratos/discussions/2452! I copied my original reply to this thread over there for anyone Googling the same problem

Looks like I have some reading to! Ta

Thanks Taylor 🙌