Open rahafjrw opened 2 months ago
Sherlouk
commented
2 months ago Out of interest, what alternatives were considered? Such as, logging in using GitHub or SIWA.
Additionally you elude to exclusive use of username+password, as opposed to Passkeys, which seems to be the direction the industry is pushing. Are there long-term considerations to support other login methods?
It's a personal decision no doubt, but I know I've been burnt by rolling my own auth on a few occasions!
daveverwer
commented
2 months ago Out of interest, what alternatives were considered? Such as, logging in using GitHub or SIWA.
Additionally you elude to exclusive use of username+password, as opposed to Passkeys, which seems to be the direction the industry is pushing. Are there long-term considerations to support other login methods?
This was actually in a previous version of this document! I don’t know how it didn’t make it across to this final one.
We considered all of these, and decided to start with self hosted. I’m not sure you’ll ever see a “Login with Facebook” or “Login with X” on the site 😂 but passkeys, Sign in with Apple, and GitHub login are things you may see added in the future.
The decision to use Cognito is part of the compromise of this decision, though. You’re correct that there are a million edge cases with authentication, and having Cognito do a lot of the behind the scenes work is part of why we think it makes most sense to start with this version of authentication.
finestructure
commented
2 months ago Any and all user information or personally identifiable information (PII) will be stored in a separate schema in the current database.
Is there a way to avoid storing PII on our end? I thought Dave had mentioned that Cognito takes care of that and all we need is the cookie. It would be great if that was achievable!
Generally, once we start handling PII in this way we'll need to run through the GDPR checklist. One thing that's missing for example is "data take-out":
It's easy for your customers to receive a copy of their personal data in a format that can be easily transferred to another company.
heckj
commented
2 months ago It took a while to get through Amazon's heavy upsell, but the User Guide link https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-hosted-ui-app-client.html seems like what you may be aiming for. I'm a bit unclear on where PII ends up living, but it seems like you can have that hosted at Amazon, and then hand out "JWT"s through the API that provide the "proof" of authentication - and can be used for some amount of authorization as well.
I suspect no matter what though, it'll be important to keep that GDPR checklist at hand.
daveverwer
commented
2 months ago It took a while to get through Amazon's heavy upsell, but the User Guide link https://docs.aws.amazon.com/cognito/latest/developerguide/tutorial-create-hosted-ui-app-client.html seems like what you may be aiming for. I'm a bit unclear on where PII ends up living, but it seems like you can have that hosted at Amazon, and then hand out "JWT"s through the API that provide the "proof" of authentication - and can be used for some amount of authorization as well.
Yes, that's exactly it.
I suspect no matter what though, it'll be important to keep that GDPR checklist at hand.
Absolutely. Just because we're getting Amazon to actually store it, it's still our responsibility.
Generally, once we start handling PII in this way we'll need to run through the GDPR checklist. One thing that's missing for example is "data take-out":
It's easy for your customers to receive a copy of their personal data in a format that can be easily transferred to another company.
This will fall into much more clarity as we implement it, but I believe the only PII we will store is an email address. Certainly I have checked that we don't log IP addresses or anything like that.
It will be clearer whether we need this feature as we implement, but at the moment I don't believe we would need it, and if we did it would be a text file with the user email address.
Goal
This project provides a base for more features, reporting, and control for package authors and maintainers.
Scope
To keep the scope of each part of this project under control, this issue is not concerned with adding any additional author-related features. This issue only creates the pages needed for authentication and a single authenticated page that will have no content other than links to logging out and to account deletion.
The entire authentication feature will be gated to the staging server even when this issue is complete and only go live to production once additional features are implemented.
The scope for the this feature going forward is much more significant than described here. See the Future Enhancements section for more detail.
Authentication system
This authentication system includes:
/login/containing email and password fields and a link to the password reset page./reset-password/with an email field and a link to the login page./logout/./portal/delete-account/functionality that removes all user data and PII for a user./portal/that contains links to the logout and delete account pages.Implementation
We will use AWS Cognito to implement the authentication portion of this feature. It takes care of password policies, email address confirmation, password reset emails, and storage of user email addresses. It can also be extended to also take care of fraud detection later, if we experience problems with that.
The user will not leave the swiftpackageindex.com domain during authentication. All communication with Cognito is through their API and the Soto Cognito Authentication package.
Password policy and confirmation/reset emails can be configured inside the Cognito control panel and we can send all email from swiftpackageindex.com. End users should not be aware that Cognito is being used unless they read the privacy policy.
We can also customise the information that Cognito stores and will start with it storing nothing but email address and (encrypted) password.
Protection of PII
Any and all user information or personally identifiable information (PII) will be stored in a separate schema in the current database.
Privacy and cookies
Before this feature goes live to the public, we will also update our privacy policy to include information about the data we store, where we store it, cookies we save, and any other privacy related changes.
Any cookies will be from swiftpackageindex.com, not from a third-party site.
Future Enhancements
Next steps for this feature will be to list managed packages within the portal page and link to sub-pages that contain the two pieces of package-specific information that currently live on the “Information for package maintainers” page: Shields.io badges and package score information.
The list of managed packages will come from connecting GitHub accounts to an SPI user account, which will add all owned packages from that account and also allowing packages to provide additional authorised GitHub accounts through the SPI manifest.
This is not yet fully specified (although has been thought through in much more detail than here, but will be the subject of future issues.