Notes on existing OpenID connection, OpenID, OAuth authentication.
bugs.python.org has two files used to allow login via GitHub, LaunchPad, and Google. The original deployment is for Python 2, so changes have to be made to work with Python3 and some of the underlying libraries are Python 3 only at this time.
Google and GitHub are supported by: https://github.com/psf/bpo-tracker-cpython/blob/master/extensions/oic_login.py and uses the https://github.com/CZ-NIC/pyoidc library. It is currently being maintained.
Launchpad is supported by: https://github.com/psf/bpo-tracker-cpython/blob/master/extensions/openid_login.py and uses https://pypi.org/project/openid2rp/ which has not changed since 2012. The source code was maintained on bitbucket which is no more.
Both use hardcoded url's and other things that should be abstracted into a config setting.
Also the exact libraries (and versions) that have to be installed, user schema changes, and target pages are not documented.
The Roundup Issue https://issues.roundup-tracker.org/issue2551239 is open for for abstracting, updating, documenting and implementing it on the Roundup Issue tracker.
Extra Docs
We want to use the github "web application flow" for OAuth apps AKA Authorization Code Flow and not the Device Authorization Flow.
Primary doc on creating an OAuth app that can authenticate against github: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app
Primary doc on getting authenticated against the created github app: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#web-application-flow
Stack overflow description of an implementation: https://stackoverflow.com/a/71741717
OKTA docs: https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
Security issue with flow from a provider but a good diagram/summary of the flow and the importance of the state nonce: https://blog.logto.io/oauth-security-recap/
Note that: Authorization Code with PKCE is not what we need. It is used for single page apps where there is no backend server to keep and use secret keys. Doc on this even though we don't need it to differentiate the two flows: https://tania.dev/oauth-pkce-authorization/
OIDC does not appear to be implemented in Roundup at this time. It builds on top of OAuth2 (which is an authorization and not authentication protocol. We use the fact that we get an authorization token as proof that the user authenticated with the provider to get the token and give it to us.) OIDC is describe in: https://www.pingidentity.com/en/resources/identity-fundamentals/authentication-authorization-standards/openid-connect.html and for the difference see: https://security.stackexchange.com/questions/37818/why-use-openid-connect-instead-of-plain-oauth2/260519#260519.
Another OIDC example: https://codeburst.io/openid-connect-client-by-example-76caf6dae55e
From my understanding, OIDC includes information that allows Roundup to verify that the token we get from the user was generated as a result of a request from Roundup. Otherwise any token generated by github's OAuth (say by another app using github login) would be accepted by Roundup (since I can use it to get the email and profile info).
I think we prevent this in two ways:
- 1) the random state nonce that we generate is compared to the code returned by the user. We compare it to verify that the code is one we used to request the login. 2) then we use the code to retrieve and store a token for the use and only accept that token for login.
I am not 100% sure that 1 and 2 are correct and sufficient though.