thunder-id/thunderid

Description OAuth 2.0 Security BCP (§4.1.3) requires that authorization servers MUST NOT allow redirect URIs using the http scheme, except for native clients using loopback interface redirection (RFC 8252 §7.3). ThunderID currently accepts http redirect URIs for any host. Registration validation in validateRedirectURIs (backend/internal/inboundclient/service.go) checks structure only (non-empty scheme, host present for web schemes, no fragment, wildcard rules) and never inspects the scheme; DCR reuses the same path. At authorization time, ValidateRedirectURI (backend/pkg/thunderidengine/providers/oauth_client.go) only pattern-matches against the registered list. There is no server config option to restrict this. The only acknowledgement is in backend/internal/oauth/oauth2/authz/service.go, which sets a showInsecureWarning query param on the login redirect when the scheme is http. That is advisory rather than blocking, and the param is unused, the only other occurrence in the repo is

Summary The consent attribute-profile filter does not distinguish between unavailable profile data and a known empty user profile. buildAttributePurposePrompt currently filters an attribute only when len(userAttributeSet) > 0. In Go, a nil map and an empty map both have length zero. As a result, when the identity provider returns a known empty attribute set, the consent flow disables profile filtering and can prompt for requested attributes that are not present for the user. Required change Define and implement the intended profile-filter contract in the default consent service: If profile data is available and contains no applicable attributes, do not create an attribute consent prompt. Preserve the behavior for profile formats that do not expose individual attribute names, if that behavior remains required. Distinguish an unavailable or opaque profile from a known empty profile. Add focused tests for nil, empty, opaque JWT/JWE, and populated attribute responses. Affected area back

What problem are we solving? Vue/Nuxt developers building apps commonly use Nuxt Auth (sidebase-auth) for authentication. There is currently no guide showing how to configure Nuxt Auth's generic OAuth2/OIDC provider support against a ThunderID server. Who are we solving this for? Primary: Nuxt developers who want to use ThunderID as their identity provider via Nuxt Auth. Goal: A copy-pasteable guide covering Nuxt Auth's generic provider configuration (issuer discovery, client ID/secret, scopes) against ThunderID. Pain: Without a guide, developers must piece together ThunderID's OIDC endpoint details and Nuxt Auth's generic provider configuration themselves. Why should we solve this now? A guide here lowers the barrier for the large population of Nuxt/Vue developers using Nuxt Auth to adopt ThunderID as their identity provider, and strengthens ThunderID's standing as a spec-compliant OIDC provider. Proposed Solution Write a guide (doc page + minimal sample) demonstrating integration b

Current Limitation The frontend currently uses ESLint for linting. ESLint's dependency tree is relatively large, increasing the overall dependency surface and requiring ongoing maintenance to address security advisories in the JavaScript ecosystem. As the codebase grows, linting also contributes to longer local development and CI execution times. Suggested Improvement Evaluate oxlint (from the Oxc toolchain) as a potential replacement for ESLint. Oxlint is a Rust-based linter with a significantly smaller dependency footprint and substantially faster execution. This evaluation should determine whether it can provide comparable lint coverage while improving developer experience and CI performance. The goal of this issue is evaluation only. no migration is expected. Tasks (⚠️ Read This) Set up oxlint alongside the existing ESLint configuration. Run oxlint against the frontend codebase. Compare rule coverage with the current ESLint configuration. Identify any unsupported or missing ru

Document issue type Type/Bug (Report inaccuracies, outdated information, or missing details in the existing content) Description Utilize the empty space in the following sections Make sure to check the responsiveness as well. NotePlease include screenshots of both the desktop and mobile views after the fix 🙌 Version 0.48.0