machete143

That is a really bad specification with no examples, no formalization, and zero references.

However, all server-side attack scenarios listed there are not possible with Hydra. Some of them also boil down to misusing OAuth2 for authentication, which is why we have OpenID Connect.

Thank you for the valuable feedback! The dev mode is indeed a very good idea - I'll probably spin up another docker-compose example with all the default things set up. Would that make it easier?

So how do people grant tokens then? They do need to log in somewhere?

What I meant to ask is if this has things like user registration, password reset flow, two-factor authentication, account takeover prevention, etc.

I think removing 3rd party dependencies is always a good idea - it keeps things lean and removes ops overhead.

Looks interesting, does this solve authentication as well? It looks like it but from quickly scanning through the readme I didn't find anything.

Also what's your reasoning for relying on 4 (etcd, consul, postgres, nats) external dependencies?

Good idea! How could that look like on windows (the guide should work on all OS and I'm no windows pro)?

I'm not sure if I understood you correctly. Delegation of authentication usually implies trust between the two parties. GitLab (the hosted version) does probably not trust stravros.io enough to allow people to log in through there.

Portier looks indeed very nice, maybe I'll set up a tutorial how to get those two working together to get full Authentication (portier) + Authorization (Hydra) with using only open source technology.

Then I hope that this makes your life easier :)

That is a valid concern. However, once a password is published (especially in docs or tutorials) it is insecure whether they are random values or not - simply because they are public and clearly linked to the product you're running.

That's why I chose to make it explicit, and thus more likely to be caught in review if done.

Yes indeed, running OAuth2 without https is madness!