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:
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 should not allow OAuth2 until the user's email has been confirmed.
From PeeringDB, 'IXP Manager @ INEX' would need the user's:
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!
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.