OAuth against PeeringDB

[barryo]

See peeringdb/peeringdb#131

Holding / tracking ticket for IXP Manager development / issues / discussion on this.

@will-h @job @nickhilliard @grizz

[barryo]

My initial thoughts on this:

We're assuming PeeringDB implements OAuth2. Just for everyone who is not up to speed on this - here's a very simple overview and shared terminology:

• https://aaronparecki.com/oauth-2-simplified/

• The Third-Party Application: "Client" - a specific instance of IXP Manager (e.g. INEX's). Big NB: when I say 'IXP Manager @ INEX' below, I mean INEX's specific installation and configuration. This can be anyone's unique install - but it is explicitly not IXP Manager 'out of the box'. It's unique to each IXP.

• The API: "Resource Server" & The Authorization Server: PeeringDB. Up to you whether these are different or the same.

• The User: "Resource Owner": a peeringDB user who wants to access 'IXP Manager @ INEX'.

From IXP Manager's end, I see the standard login box or a 'Login using PeeringDB' (assuming said option has been enabled in the specific IXP Manager instance). I'm sure we all know what I'm talking about but image attached for clarity:

To make this work, third party applications like 'IXP Manager @ INEX' will need to register with PeeringDB and get a client ID and secret. Probably also provide a name ('INEX IXP Manager'), an icon (INEX logo) and an explanatory note. When The User is redirected from 'IXP Manager @ INEX' to PeeringDB and asks to allow 'IXP Manager @ INEX' access to their data (detailed below), the logo, name and explanatory note should be displayed. This is pretty much standard practice.

'IXP Manager @ INEX' would then receive an AUTH_CODE in the redirect back from PeeringDB. Using this AUTH_CODE, 'IXP Manager @ INEX' would talk directly to PeeringDB and exchange this for authorization code.

• PeeringDB would record the fact that 'IXP Manager @ INEX' has been given access so the next time the flow is seamless.
• 'IXP Manager @ INEX' would create (or update) the local user with the PeeringDB authorization code

PeeringDB should not allow OAuth2 until the user's email has been confirmed.

From PeeringDB, 'IXP Manager @ INEX' would need the user's:

• email address
• list of associated ASNs with user group (read/write matches member/admin?) for each

Then IXP Manager would grant this user access to any customer(s) on IXP Manager with matching ASNs.

[on IXP Manager, we will put knobs that will allow an IXP or network to opt out of this on a case by case basis]

As part of this, I'll write a PeeringDB provider for Socialite: https://socialiteproviders.github.io/

Totally ignoring refresh tokens, etc for now!

[barryo]

This is now complete and documented here: https://docs.ixpmanager.org/features/peeringdb-oauth/

It will form part of the v5.2.0 release in the next couple of weeks.