Product design decision: How to handle GitHub login process

[MahdiBaghbani]

1st Option

Authenticate against GitHub using :

Authorizing OAuth Apps

Pros

1. straightforward to implement
2. automated and doesn't need user to do additional tasks

Cons

1. privacy issues as in CYB has access to everything

2nd Option

Authenticate using fine grained tokens:

this is new (still Beta) feature of GitHub that allows user to create customized tokens which can grant access to specific repositories.
fine grained tokens

Pros

1. user has complete control over what CYB can see

Cons

1. user has to generate a token and paste it into CYB, more complicated than for option 3
2. still in beta

3rd Option

another interesting thing is machine users, probably fits our case with CYB.
machine users

Pros

1. user has complete control over what CYB can see
2. changes show up under CYB's name
3. configuration is more flexible than for option 2 (more intuitive way of setting access levels)

Cons

1. user has to add a user to a repo (still, less complicated than the steps for option 2)

[michielbdejong]

While I understand the big advantage of options 2 and 3, and strongly sympathise with it, I would still tend towards option 1 for what we implement now, I think this is also what most existing systems in our situation choose, so it's what the user expects.

Then next year we can add option 3 as an improvement / new feature, gives us a new press release opportunity :)

[mlesmenio]

Might be worth looking into option 2 again when time to implement option 3 comes.

[MahdiBaghbani]

I think option 1 is more suitable for CYB right now, we just need an app to work.

[michielbdejong]

@yasharpm do you agree with choosing option 1, at least for our initial launch version of CYB?

[yasharpm]

Option 2 sounds nice but being in "beta" scares me. It usually means that there will be quick changes to how it works and we don't have that kind of attention span! Being complicated for the user is also a con. Maybe they will make is easy for the user when the feature is completed and not a beta anymore! Then we can definitely look into it.

Option 3, I am against it. Because then we would have to register a user on Github for the CYB. If the account can be auto created through APIs, it is still complicated for the user to grant permission to a random username they'd have to copy and paste and then check if it worked. More likely the account can not be auto created, then it will be more painful to setup a new instance of the CYB on your own server. And when the CYB server is no longer used, that Github account will still live with access to many repositories which makes it a security risk. Overall I don't think it fits our use case well.

So, I prefer option 1. And about the extra access the CYB gets, we can argue that it is an opensource software so you know what is running on your own server if you don't trust the shared server to be running the same code.

[michielbdejong]

we would have to register a user on Github for the CYB
[...]
it will be more painful to setup a new instance of the CYB on your own server

Well, strictly speaking, the server admin would of a CYB instance would register a user for that instance. So for instance we would register one for https://connectyourbooks.com and maybe a separate one for https://time.pondersource.com . For comparison, with option 1 you have generate one API key for each instance, which can also not be automated, so it's not that different?

when the CYB server is no longer used, that Github account will still live with access to many repositories which makes it a security risk

Then you would delete the user (just like you would delete the API key in the option 1 situation)

[michielbdejong]

So I think we have consensus, we unanimously chose option 1 :)