Feature Request: Google or Github oAuth

[koleror]

First of all, thank you for your awesome service!

It would be awesome if you could implement one or more oAuth providers like Google or Github. That would avoid having a distinct user database, with passwords to rotate and revoke when a developer is leaving.

I'm not sure how big it can be as I've seen an interface? I'm willing to work on it if you can point me in the right direction, and confirm me it won't be too tricky to implement.

[tomelliff]

I was considering looking into this but I'm not sure how I want to handle non user accounts for deployment/CI accounts and also access control if you don't just want users to only have read permissions.

AFAIK there's no good way of doing hybrid backends in PyPICloud so you couldn't combine it with a file auth backend but could be wrong on that.

[koleror]

Hmm I see... In fact the best would be to separate the auth layer from the authorization. That way, we could login using Github or Google SSO, while the authorizations and groups would be stored on MySQL (and configured on an interface). For now, I created a AWS Secrets Manager auth class (https://github.com/stevearc/pypicloud/pull/164), which has the advantage of being serverless. What do you think about it? Do you think you may merge it or should I make it an external dependency?

[stevearc]

Hmm...yeah it may be a good idea to split authentication from authorization. That might be too involved to refactor right now, but there may be an easier way to support SSO and OAuth. I'll investigate and see if I can find some sort of compromise

[stevearc]

How do you envision the Github/Google SSO/OAuth working? It would be...I don't want to say "easy", but maybe "straightforward" to build that into the pypicloud web interface. But most uses of pypicloud involve using pip to install and setuptools/twine to upload. Do you want to somehow use those services to auth pip and twine? Or is this something that would purely be for users that are logging in and browsing the web interface?

If it's the first, I could see a flow where I build in a sign-in flow on the website that generates a token that the user could then use as a password for pip. The problem is that for Google sign-in, I don't see a good way to do it and preserve the features you want (automatically revoking permissions when a dev leaves). Google will give me an ID token that I can verify, but I don't believe that the token will be invalidated if the user leaves the org.

For github, I think that you could generate a token that has the read:org scope and store that server-side (so pypicloud would have to be using SQL or something on the backend). Pypicloud could then generate and give the user a token to use with pip and for each request (or every N minutes) check to make sure that user is still in the required org. Then you could configure the groups/package permissions like you usually do with the SQL backend.

Does the Github case sound like it would work for you? Do you see any potential problems with it?

[ntrepid8]

What about doing something like Firebase Authentication and let users configure the different types of Authentication they want to allow?

I think that would cover the Google and GitHub use case along with providing the ability to check a revocation list in the event that immediately terminating access is a concern. I think we could then provide pip with a custom token and use that as the password for basic http authentication and include authorization claims in the custom token. The user_id could be used for the username for http basic auth.

Thoughts? I'm not 100% sure of the solution but I do have experience using Firebase in a similar manner and if there is not a fundamental objection, I could take a crack at a PR to provide an implementation.

I'm pretty sure this would enable OAuth across a choice of providers without creating any additional server side dependencies for pypicloud. The admin would just need to create a Firebase app and provide the credentials to pypicloud as configuration.

[stevearc]

That sounds great! I didn't even know Firebase had an auth offering. I'd be happy to review a PR that adds this to the codebase!

Two things I would change/look out for:

See if you can find some way to associate permissions with a logical group. You don't want to allow anyone with a Google/Github/Twitter account to log in, so you'll have to find some way to determine if the users meet some criterion. For Github it may be org or team membership. For Google it may be email domain. I didn't see any docs in Firebase for doing something like this, but you're more familiar with it than me so maybe you know of something.

Instead of generating a firebase token to use with pip, I'd recommend doing the same thing as the signup token https://github.com/stevearc/pypicloud/blob/42e10c1fab8e72633d3f2b9c4e1b22675cb531b6/pypicloud/views/admin.py#L175-L181 and https://github.com/stevearc/pypicloud/blob/42e10c1fab8e72633d3f2b9c4e1b22675cb531b6/pypicloud/access/base.py#L524-L539 A firebase token will (I think) require an API call every request to verify it, but these tokens just need an hmac.

[KerberosMorphy]

If it's the first, I could see a flow where I build in a sign-in flow on the website that generates a token that the user could then use as a password for pip.

It may not be entirely link to this issues, but I just bump into that. I was wondering how to handle 2FA/MFA.

I know PyPI have a 2FA option now, it is not enforced for uploading package (for now) but it's pretty clear that they'll go in that direction. They have API Tokens that you can create to upload package.

They are configured in the .pypirc as follow:

[pypi]
username = __token__
password = pypi-Aadfvdafvadfvadfvadfvd.....vavadfadva
repository = https://upload.pypi.org/legacy/

Where username must be set as __token__ and the password start with pypi- followed by the token.

I understand the issue where removing someone access (LDAP, OAuth) must impact those API Tokens so anytime we use our token the backend should validate that the user is still valid.