ory / oathkeeper

A cloud native Identity & Access Proxy / API (IAP) and Access Control Decision API that authenticates, authorizes, and mutates incoming HTTP(s) requests. Inspired by the BeyondCorp / Zero Trust white paper. Written in Go.
https://www.ory.sh/?utm_source=github&utm_medium=banner&utm_campaign=hydra
Apache License 2.0
3.2k stars 349 forks source link

Implement PASETO as a more secure alternative to JOSE #566

Closed sycured closed 2 years ago

sycured commented 3 years ago

Hi, PASETO exists for a long time now and Okta implemented it as a more secure alternative to JOSE.

Regards

aeneasr commented 3 years ago

Thank you for the idea! Could go into a bit more detail where this is used for example, or what parts of ORY Oathkeeper should support it? Is this for example integrated in Kubernetes, Istio, Linkerd?

sycured commented 3 years ago

With tools that I use/will use soon:

And a lot of private webservices

ycgambo commented 3 years ago

I'm trying to implement ory ecosystem together with kong and istio for several months, and I'm getting stuck at find out a AuthService replacement of Kong instead of using Ambassador according to this blog. As the introduction says If you want to use another API Gateway (Kong, Nginx, Envoy, AWS API Gateway, ...), Oathkeeper can also plug into that and act as its Policy Decision Point., It's quite confusing on how to use the /judge decision api. This issue here is the closest thing I reached so far if I don't want to write a homemade lua plugin for Kong.

ycgambo commented 3 years ago

this is what I'm trying to do: I hope I can use oathkeeper as ory service gateway to inject incoming request a X-User-ID header. So that I can easily unplug this service when I want to since it's not production ready.

image

aeneasr commented 2 years ago

I am closing this issue as it has not received any engagement from the community or maintainers in a long time. That does not imply that the issue has no merit. If you feel strongly about this issue

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you to anyone who participated in the issue! 🙏✌️