Login Failure with OpenID Connect Due to Incorrect Base64 Decoding of Japanese Characters in JWT

[miikun77]

Description

The current implementation of base64 decoding in the frontend application leads to incorrect handling of non-ASCII characters, specifically Japanese characters. This leads to a complete login failure when processing user information extracted from JWT tokens received during the OpenID Connect login flow.

Current behavior

The code responsible for decoding the base64-encoded payload of the JWT token (obtained via OpenID Connect) incorrectly replaces only the first instance of - with + and _ with /. Additionally, it fails to properly decode non-ASCII characters.

Steps to reproduce

1. Attempt to log in to Vikunja using OpenID Connect.
2. Use an account where the returned JWT token contains Japanese characters in the user information.
3. Observe that the login process fails.

Additional context

The current code for base64 decoding in frontend/src/stores/auth.ts is:

const base64 = jwt.split('.')[1].replace('-', '+').replace('_', '/')
const info = new UserModel(JSON.parse(atob(base64)))

This code only replaces the first instance of - and _. A correct implementation should use regular expressions with the g (global) flag to replace all occurrences.

// Replace all occurrences of - and _
const base64 = jwt.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')
// Decode correctly, handling non-ASCII characters
const info = new UserModel(JSON.parse(decodeURIComponent(window.atob(base64).split('').map(function(c) {
        return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
    }).join(''))))

Reference

This issue is similar to a problem reported in the microsoft-authentication-library-for-js repository: AzureAD/microsoft-authentication-library-for-js#985

Note

I am including the code directly in this report because my Gitea account is not yet approved. I apologize for any inconvenience this may cause.

Vikunja Version

v0.24.6

Browser and version

Chrome/131.0.6778.206

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

[kolaente]

Is that reproducible on the demo when you set the accounts' name to contain non-ascii characters and then log in again?

[kolaente]

I'm unable to reproduce this with a local account on the demo with a display name set to Japanese or an openid account with a Japanese name.

Can you add more details about how to reproduce this?

[kolaente]

From your analysis, it seems like this is not specific to Japanese characters in the token?

[miikun77]

Sorry for the delayed reply.

Thank you for your feedback. I tested by setting the account name to “日本語憂鬱髙” and confirmed that the issue occurs when decoding the Base64 payload containing Japanese characters in the JWT token.

[kolaente]

Did you reproduce it on the demo?

[miikun77]

On the demo, I can't use OpenID Connect, so I can't reproduce the issue.

[kolaente]

But can you reproduce it on the demo if you change the name in the settings?

[miikun77]

It seems like the issue is related to OpenID Connect, not just the name change in the settings. The problem appears to be in transferring OpenID token-related data.

[kolaente]

I've created a test account with the name 日本語憂鬱髙 in my authentik instance and was able to log in through that without issues.

If you're seeing the problem in the frontend, it might be unrelated to openid auth since the openid auth token is parsed on the server only.