2068548 - Add OAuth2 authentication support for Seznam.cz

Status: RESOLVED FIXED

(Thunderbird :: Security, enhancement)

Description

[Petr Stefan (petr.stefan)]

Attachment: manifest.json

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:154.0) Gecko/20100101 Firefox/154.0

Steps to reproduce:

Seznam.cz is a leading freemail provider in Czech Republic. We support OAuth2 authentication for mail, calendar and contact resources and we want our users to benefit from that.

In Matrix chat conversation we figured that Seznam.cz could be a great candidate for testing the new system add-on feature, that will provide more flexibility than hardcoding credentials into OAuth2Providers.sys.mjs.

I already have a working Thunderbird add-on, manifest.json with my client_id is attached to this report.

You can register Thunderbird OAuth2 client yourself, on https://vyvojari.seznam.cz/oauth/doc?lang=en (sorry that the page is only half english, I can guide you through). Endpoints, hostnames and scopes are part of the manifest.

I'm willing to help with coding or testing if needed. The OAuth2 login is already supported for all accounts (official domains @seznam.cz, @email.cz, @post.cz and all custom domains from our EmailProfi service - users can bring their own domain into our ecosystem).

Our public autoconfig https://email.seznam.cz/mail/config-v1.1.xml is already updated with oAuth2 section.

Comment 1

[Toby Pilling [:tobyp]]

Hi, does this add-on work for you? When I install it and try to set up an email account such as [e-mail] I get an error:

OAuth: invalid_request
Redirect uri not allowed: http://localhost:61705

We have seen similar errors with other providers such as Yandex who ended up adjusting their systems to handle the port we add as per RFC 8252.

If I'm missing something, can you let me know?

Comment 2

[Petr Stefan (petr.stefan)]

Attachment: manifest.json

Comment 3

[Petr Stefan (petr.stefan)]

Hi, thanks for your report.

It seems that we all had our tokens from older Thunderbird version with internal browser and nobody tried to do a complete login after I updated the plugin for version 153. Sorry about that, definitely our mistake.

I was able to consult this issue with our login team and they did amazing job fixing this in a great time. Now I can confirm that the plugin is working for me fine. Please try it yourself, it should just fork for you now.

Sorry for inconvenience on our side.

Comment 4

[Toby Pilling [:tobyp]]

Wow, you/they are super fast! Thanks

It seems like I need to wait until the remote update pieces of bug 2057391 have been sorted, so we'll work on getting this added to core code in the interim.

Comment 5

[Toby Pilling [:tobyp]]

Did you see my question in chat....? I was setting up our own client ID in your systems and ran into something...

I noticed that the details baked into your manifest.json uses PKCE and doesn't include clientSecret - great! But I didn't notice that option in the web UI when I set up our clientID - 7c0b7108b69c671152f76796be1779fbb634cddfa7e0c187

Did I miss something?

Comment 6

[Petr Stefan (petr.stefan)]

I consulted that with our login team and we currently have all clients PKCE-enabled by default. It may be a bit unusual, but in our threat model (permissions are not base on client id and all clients can request the same scopes) it shouldn't be a practical security issue.

Comment 7

[Toby Pilling [:tobyp]]

Attachment: Bug 2068548 - Add built-in OAuth2 support for Seznam.cz. r=#thunderbird-back-end-reviewers

TB-Tools-Id: 6aff1d22-8357-4e45-b81a-a55eb51fab60

Comment 8

[Toby Pilling [:tobyp]]

Hi Petr,
As you can probably see, I worked on this request recently and thought that I was done - but I got a request to make changes that may be possible - but dependent on some changes on your servers.

After the feedback in my patch I adjusted the code locally and in the Oauth client registration in your developer portal, to configure the redirect to be http://127.0.0.1/seznam as per the details you can read about in bug 2068725.

However when I tested with that configuration on both sides, I got:

OAuth: invalid_request

Redirect uri not allowed: http://127.0.0.1:56290/seznam

So because our code injects the port, it looks like your validation code no longer matches http://127.0.0.1:56290/seznam with http://127.0.0.1/seznam. Might it be possible for your team to adjust your logic? You can read about this approach here:
https://datatracker.ietf.org/doc/html/rfc9700#name-mix-up-defense-via-distinct

Justin if there is any more detail you can provide or if I got some of this wrong, can you please let Petr know?

Comment 9

[Justin Tracey [:jtracey]]

That's all correct, though the better alternative would be if the server added support for the issuer identifier field, as specified in RFC 9207. The unique endpoint gets most of the benefit, so if it's significantly easier, it'll work, but RFC 9207 is more robust and should be pretty simple server-side (basically just needs iss=https%3A%2F%2Flogin.seznam.cz added to the response).

Comment 10

[Ondřej Žára]

Hi,

just chiming in. I am Peter's colleague and I work on the Seznam OAuth implementation. I believe I fixed the port-independent redirect_uri comparison algorithm -- please re-test and let me know should the problem persist (ideally mentioning the client_id you were trying to use).

I also added the iss parameter to the response, because it seemed like a trivial thing to do.

Comment 11

[Toby Pilling [:tobyp]]

Wow Thanks a lot Ondřej, that was speedy! We've tested this and will merge into our 158 release.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a64c2f584cbe
Add built-in OAuth2 support for Seznam.cz. r=jtracey