Cornerstone Building Brands Authentication
Two authentication postures on one host. The wp/v2 content read surface is anonymous — posts, pages, media, news, industry, leadership, categories, tags, news_category, news_solution, search, taxonomies, types and statuses all return HTTP 200 with no credential — while the MCP server routes, the WordPress Abilities registry and every administrative WordPress route (settings, menus, menu-items, block-types) require a bearer token or a WordPress session and answer 401. Probed rather than derived: the derived Content API declares no securitySchemes because its documented operations need none, so a spec-only derivation would have recorded "no authentication" and missed the OAuth server entirely. The company publishes no authentication documentation of its own; everything here is read from the discovery documents and observed responses. The separate Customer Portal (portal.cornerstonebuildingbrands.com) signs in with Microsoft Entra ID (MSAL) — observed in the portal's public JavaScript bundle, not documented — and is out of scope for this profile.
Cornerstone Building Brands secures its APIs with none and oauth2 across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode flow(s).
Security Schemes
Source
Authentication Profile
Work with this as data
Every security artifact here is available over the APIs.io API and to AI agents over MCP.