thunder-id/thunderid

Current Limitation Currently backend/internal/system/http exposes four constructors and each one bundles a fixed combination of timeout, redirect policy and SSRF dial guard. However this has the following concerns. The dial guard isn't selectable. It only comes with NewHTTPClientWithCheckRedirect, so a caller gets it as a side effect of wanting a redirect policy. The OAuth authenticator dials the token and userinfo endpoints from the connection config with an unguarded client, while the JWKS resolver is guarded. Same kind of URL, different treatment. Every new combination needs another constructor. A general method taking the options positionally doesn't help either, since the next option changes the signature again. The HTTPClient struct is exported although nothing outside the package uses it. Suggested Improvement The idea is to take a config struct, so a new option is a new field and existing callers don't change. // HTTPClientConfig carries the options for an outbound HTTP clien

Current Limitation Two related gaps make it awkward to add a phone number attribute to a user type schema. 1. There is no phone number attribute in the schema attribute library. When building a user type schema in the Console, users pick from a predefined library of attributes defined in frontend/packages/configure-user-types/src/constants/attributes.ts. That list has 32 entries but none of them is a phone number, so a user who wants one has to add a fully custom property by hand. The omission looks like an oversight rather than a deliberate choice, because the library already contains phone_verified (attributes.ts:204) with the display name "Phone Verified". There is a flag to mark a phone number as verified, but no phone number attribute to go with it. The equivalent email pair is complete: both email and email_verified are present. The built-in Person user type does define mobile_number, which is what makes its absence from the library surprising to users comparing the two. 2. The b

Document issue type Type/Bug (Report inaccuracies, outdated information, or missing details in the existing content) Description md ### Writing Tests A flow is a YAML file: a header naming the app under test, then a list of commands after the `---` separator. Bug When the Code UI overflows, the UI looks buggy. Version 1.0.0

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