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.

No, ignore the spec (it's just a list of traits i'd like to suggest), design issues are outlined after it.

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?

Yes definitely. Although you could build a new image based off of the original one, add a bash script that sets it all up for you and overwrite the entrypoint i never like that sollution. It should be something that the software supports out of the box as it plays into one of the strengths of docker, easily spinning up and taking down instances.

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?

Hi, you can use resource owner password credentials grant which is part of OAuth2 spec:

https://github.com/RichardKnop/go-oauth2-server#resource-own...

It's basically a login with username and password.

If you want a fully fledged identity provider on top of OAuth2 (so create / update user account, password reset), I have a sample project which extends on the oauth2 repository and builds a full identity provider on top of it: https://github.com/RichardKnop/example-api

About dependencies: only two are required - etcd/consul and postgres. There is no other requirements.

Originally I developed this project while deploying to a CoreOS cluster so etcd was a native choice for storing app configuration in a distributed key store. Consul support was added later in form of a contribution as an alternative to etcd.

I also want to remove dependency on etcd/consul completely and allow just simple configuration via environment variables to make the projec more portable.

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.

No it doesn't have things like user registration password reset flow etc. I wanted to keep the project just as straight OAuth2 server based on spec, nothing more.

I have another project which I sometimes use as a boilerplate when working on ideas and I need a simple API for my prototyping. It contains all those things as registration, password reset flow etc:

https://github.com/RichardKnop/example-api

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

The go-oauth2-server contains simple web forms (which you can style to match your UI) to handle the full authorization and implicit flows of OAuth2 so you would connect to the oauth2 server from your app, log in and be redirected back to the app with authorization code and then the app can obtain access and refresh tokens from the oauth2 server via API call.

This is a normal authorization flow people are used to from Facebook/Github/LinkedIn, works the same way. See README for images of how the forms look out of the box, without any customization.

If you want to have in app login system, then for such scenario usual way I have implemented this before is to have a separate frontend layer and it works something like this:

1) Frontend (mobile/web app) displays login form

2) Enter username and password

3) Use resource owner credentials grant to obtain access token via API call

4) Now you can make authenticated API calls with the access token (and use refresh token in the background to renew your access token)

In case of web application frontend (let's say NodeJS app), the app would store client ID and secret server side (so you would proxy all requests from client app to Node proxy because we don't want to keep client ID and secret in public JS).

Just in addition to my answer above, yes there is a way to log in in my project. See the README which showcases the built in web forms.

The database contains a simple table to store usernames and passwords for resource owner credentials grant.

There is no API for registering a new user account though which is what I meant.

You can do that manually buy running SQL statement to insert new username and password, or by using the cli and load it from fixtures.

How you handle registering user accounts, updating user data, resetting passwords, all of that I wanted to leave open to implementation as there are various ways in which this can be done and other people might prefer one over another so I didn't want to prescribe a specific way to do it.

I offer my preferred implementation using JSON HAL in my extending project I mentioned above. If anybody is interested, they can still fork my example-api and customize that.

Test users available as fixture:

https://github.com/RichardKnop/go-oauth2-server/blob/master/...

  go-oauth2-server loaddata \
    oauth/fixtures/scopes.yml \
    oauth/fixtures/roles.yml \
    oauth/fixtures/test_clients.yml

To insert some test data to database.

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.

Why does Gitlab have to trust anyone? It's the user that has to trust stravros.io not to tell Gitlab that other people are authorized.

It's no different than a regular email/password (with password recovery): if I register with user@stravros.io, then that email server becomes empowered to give access to the Gitlab account to anyone it wants. But that's not Gitlab's problem.

See also OpenID.

Exactly, and OpenID connect adds an authentication layer over OAuth2 for this exact purpose. If we manage to build that future, it will be very useful and quite exciting, at least to me. There won't be compromised passwords any longer, just the one password you can easily change.

You are ten years too late. The original OpenID did exactly this, and quite a few sites (especially tech focussed sites) let you sign in with it. Except then along came Google and Facebook with their proprietary login systems, and everyone jumped ship to those as they offered access to profiles rather than just a domain and possibly email address.

We first worked in this problem at Netscape just after the AOL acquisition in 1998. It turns out to be impossible because: show me the money. Something we figured out within a few weeks back then.

Which is precisely why DNS and SMTP have failed miserably.

Please elaborate on how DNS has failed? It seems to me that everyone uses DNS all the time and is an essential component of the Internet as we know it, but you and I may have differing notions of failure.

I assume he was being sarcastic

Anyone would think the internet has become more closed in recent years or something

> You are ten years too late.

As in, what I want has been working for ten years?

I'm obviously not late at all, since websites still won't let me delegate my auth.

The few that allowed OpenID 10 years ago did let you delegate your auth. OAuth and OpenID Connect killed that.

I don't care that some technology exists. I want it to be widespread. OpenID had huge usability problems.

Not just the data but also using Facebook or Google accounts means your users are much more likely to be real people instead of spam bots.

If you have questions for the portier side of things for that, send me a mail (in profile). A tutorial like that would be very cool.

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.

I'd suggest using something like:

  export SYSTEM_SECRET=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
  echo "SYSTEM_SECRET is $SYSTEM_SECRET"

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

Rough equivalent in PowerShell would be:

  @(48..57 + 65..90 + 97..122) | Get-Random -Count 32 | ForEach-Object -Begin {$secret = ''} -Process {$secret += [char] $PSItem} -End {$env:SYSTEM_SECRET = $secret; Write-Host "SYSTEM_SECRET is $secret"}

My Powershell-fu isn't quite up there. What's the first part of that block? Is that concatenating arrays of ranges of char codes?

Yes, it just creates an array of the decimal values for ASCII A-Za-z0-9. By default Get-Random just returns a random unsigned int, but if you pass in an array of objects it will select a random object from the array.

Note that Get-Random is not cryptographically secure, it's just seeded by the time stamp of the start of the session.

Linux noob here: what's the fold for? How is that secret different from doing something like

tr -dc A-Za-z0-9_ < /dev/urandom | head -c 32

?

The difference is that fold will add a trailing newline. Another option is to add an '; echo' at the end of the operation.

And yes the "cat" is not necessary.

One solution could be the app/service could have some dummy passwords built in which you can use for tutorials but it will refuse to use them if supplied.

Good point, Hydra does this to for things like missing TLS encryption but not yet for secrets (it only rejects secrets that are too short). I've tracked this here: https://github.com/ory/hydra/issues/573

It seems like the simplest thing, then, would be to use a secret that is too short in your documentation and make note of both the fact that it's too short and what the requirements are for a good secret.

Of course, this runs the risk that a user will simply "salt" the sample you provide up to the necessary length, which makes the length of their secret effectively the difference between the minimum length and the sample length.

Yes indeed, running OAuth2 without https is madness!

It's not just madness, TLS is a MUST in several places in the oauth2 spec.

In fact, they managed to remove a lot of oauth1 madness (all the complex signing stuff) by simply requiring TLS and let that layer deal with it.

If you're not into reading the article itself and want to check out the technology first, here's the link to github: https://github.com/ory/hydra

If you have any questions, feel free to ask ahead.