News
OpenID Discovery vs security.txt on Public Origins
November 30, 2024
OpenID Discovery vs security.txt on public origins is login metadata versus researcher contact. https://issuer.example/.well-known/openid-configuration (OpenID Connect Discovery) lists authorization, token, and JWKS URLs so clients can configure themselves. It is supposed to be public for that issuer. security.txt is a different well-known file for vulnerability disclosure. Mixing them is how teams hide OIDC behind a login and break every app, or paste an internal Keycloak URL into production discovery. Do not put client secrets in the document. JWKS is public keys, not private keys. RoastMyOpsec does not score openid-configuration or require security.txt. Missing discovery on a marketing host that is not an IdP is not an F.
The practical difference
If this hostname is not an authorization server, you do not need openid-configuration. A brochure that proxies /oauth to a hidden IdP should not publish a discovery document that names the internal host. security.txt still belongs on the brand origin if you want reports.
assetlinks.json and apple-app-site-association are app-link files. The web app manifest is PWA metadata. All are public catalogs with different jobs.
How to choose what to publish
IdP production origin: HTTPS discovery + JWKS, no secrets, issuer matching the cert name. Marketing origin: skip OIDC files unless you really issue tokens there. Staging issuers stay on staging hostnames. Redirect URIs in clients must not be open redirects — see tokens in URLs.
| File | Audience | Must not contain | Takeaway |
|---|---|---|---|
| /.well-known/openid-configuration | OIDC clients | Secrets, internal issuer hosts | Public by design on an IdP |
| JWKS URI from discovery | Token verifiers | Private signing keys | Public keys only |
| /.well-known/security.txt | Researchers | VPN hostnames | Different well-known |
| assetlinks / AASA | OS App Links | Debug team IDs | See assetlinks vs AASA |
What the roast can prove
A 404 on discovery is not a finding on a marketing site. A 200 that is HTML from a SPA catch-all is a product bug for OIDC clients. The roast does not parse JWKS. Pair with dangling CNAMEs if an old issuer name still resolves.
Common mistakes
The first mistake is discovery issuer: http://localhost:8080 copied from Keycloak.
The second mistake is putting client_secret in the JSON because 'it's well-known.'
The third mistake is treating missing openid-configuration like a missing CSP on roastmyopsec.com itself.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is public OpenID discovery a vulnerability?
- No, for an IdP. Internal hostnames or secrets in the document are the miss.
- Do I need discovery on a marketing site?
- Only if that host is the issuer. Otherwise skip it. Missing it is not a roast F.
- Does RoastMyOpsec fetch openid-configuration?
- Not as a scored path. security.txt is also not required to pass.