Skip to content

Fix markdown issues #432

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tashian merged 1 commit into from
Sep 8, 2025
Merged

Fix markdown issues #432

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions platform/core-concepts.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
updated_at: July 28, 2025
updated_at: September 08, 2025
title: Core Concepts
html_title: Smallstep Core Concepts
description: High-level overview of Smallstep platform components and concepts, and how they work together to protect your resources and provide strong assurance of device identity.
Expand Down Expand Up @@ -340,7 +340,7 @@ sequenceDiagram

The resource is configured to trust SSO for login. The Single Sign-on (SSO) provider (aka Identity Provider or IdP) is configured to require a hardware-bound device certificate at login.

An important nuance to this pattern is that the IdP only verifies Device Identity during sign-on as a condition of issuing a *bearer token*. The bearer token—not the device certificate—is then used to access the Resource. Bearer tokens can’t be device-bound. They can be exfiltrated **and used on different devices. Key protection is hardware bound **at login, but it is software protected at access time.
An important nuance to this pattern is that the IdP only verifies Device Identity during sign-on as a condition of issuing a *bearer token*. The bearer token—not the device certificate—is then used to access the Resource. Bearer tokens can’t be device-bound. They can be exfiltrated and used on different devices. Key protection is hardware bound at login, but it is software protected at access time.

This pattern can be combined with the middlebox pattern, if the middlebox is configured to authenticate the IdP-issued bearer token.

Expand Down
2 changes: 1 addition & 1 deletion tutorials/wifi-authentication-webhooks.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Your webhook server should expect the following request format:
- Headers:
- `X-Smallstep-Webhook-ID:` A UUID for the RADIUS webhook making the request
- `X-Smallstep-Signature:` Hex‑encoded HMAC‑SHA256 of the raw request body using the webhook’s signing secret
- `Authorization:` Optional. Either "Bearer <token>" or HTTP Basic auth, if configured.
- `Authorization:` Optional. Either "Bearer &lt;token&gt;" or HTTP Basic auth, if configured.
- Body (JSON):
- `timestamp`: The RFC8222 timestamp of the request
- `x509Certificate`: A JSON representation of the certificate that follows [this data structure](https://github.com/smallstep/crypto/blob/master/x509util/certificate.go#L17). Additionally, there is a `raw` field containing a base64-encoded DER representation of the client certificate.
Expand Down