Google login provides no security (let's at least inform users)

[Elijas]

Context

In my application, I modified st-paywall to have "a private client's area" after Google login, but then immediately realized that it was not secure, so I decided to create this PR to let others know.

Description of the issue

Currently, logging in with Google and using

https://github.com/tylerjrichards/st-paywall/blob/35dd9b4a29ddf8b704f7abaf14714644292d482a/src/st_paywall/google_auth.py#L26

does not provide any additional security than

tell us your email and we'll trust that you are who you say you are

In other words, the JWTs are not being verified for their signature, which could potentially lead to security vulnerabilities, such as token forgery and unauthorized access.

Reasoning

While this may or may not be the intended behavior of st-paywall, some people may want to use/modify st-paywall in their application in a way that provides their users some "logged-in client area", without knowing that the access to it is potentially insecure.

Suggested change to README.md

Before implementing a full solution, I suggest we inform users and contributors of this potential security issue. I propose adding an admonition box to the README.md file. This will serve as a temporary but important notice until a proper fix is in place.

Add this text box to the README.md:

Preview

[!WARNING] As of now, logging in with Google in our application is similar to just entering your email address - user identity is not verified. This means that anyone can access everyone's client area by just knowing their email address, without actually being logged in to the Google account.

Source code

> [!WARNING]
> As of now, logging in with Google in our application is similar to just entering your email address - user identity is not verified. This means that **anyone can access everyone's client area by just knowing their email address**, without actually being logged in to the Google account.

Thanks!

[tylerjrichards]

hey so sorry for getting this much later, I have been googling around and don't actually understand much about jwt's or what this actually does. Let me look into it.

[Elijas]

hey so sorry for getting this much later, I have been googling around and don't actually understand much about jwt's or what this actually does. Let me look into it.

Problem

Let me give an oversimplified (not entirely correct) example, that gives the intuitive idea of the vulnerability.

Legitimate Authentication Example:

1. I'm Alice and logging in to mystreamlitapp.com with a Google account. I click "Login with Google"
2. Google redirects to mystreamlitapp.com/callback?code={"user": "alice@gmail.com"}
3. mystreamlitapp.com says "Hi Alice, you are logged in!"

Impersonation Attack Example (Token Tampering):

1. I'm Bob and I'm logging in to mystreamlitapp.com with a Google account. I click "Login with Google"
2. Google redirects to mystreamlitapp.com/callback?code={"user": "bob@gmail.com"} But I change "bob" to "alice"
3. mystreamlitapp.com says "Hi Alice, you are logged in!", even though I'm Bob

Solution

Now, let me quickly summarize https://github.com/tylerjrichards/st-paywall/pull/51

JWT verification is the mechanism that would prevent this kind of attack. When the application receives the callback with the JWT (in this case, simplified as a JSON object in the URL parameter), it should verify that the JWT has not been tampered with. This is typically done by checking the JWT's digital signature against the public key of the issuer (in this example, Google). If the verification process fails (which it would in the case of Bob trying to log in as Alice), the application should reject the login attempt. This ensures that only tokens issued by the trusted authority and for the correct user are accepted, effectively closing the door to such impersonation attacks