Okay, my analysis is complete! Here are the core changes to Ktistec required for Mastodon API compatibility:

• PKCE (Proof Key for Code Exchange) must be optional: Because Mastodon makes PKCE optional, clients don't support it, which means other servers can't require it. PKCE (and the code_challenge parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.
• Support for the client_credentials grant type: The client_credentials grant type is used to grant a client app-level access without requiring user authentication. Mastodon requires this for some of its "public" API endpoints. This necessitates a change to the database schema to allow a null account id in the client secrets table.
• Addition of a created_at timestamp property: Mastodon requires a non-standard created_at property in the body of the /oauth/token endpoint response instead of (in addition to) the standard expires_in property.
• Support for both form-encoded and JSON request bodies: This isn't a Mastodon requirement per se but popular clients clearly demand some latitude in what they send.
• WebFinger must accept requests with no resource parameter: This is honestly a bug on my part.
• Mastodon-compatible endpoints: A boatload of them. Clients expect many endpoints and don't gracefully degrade if they're not present. Really I should just implement features like pinned posts and bookmarks...

The only thing here that gives me heartburn is that PKCE is not required.

#ktistec #mastodonapi #oauth

Okay, my analysis is complete! Here are the core changes to Ktistec required for Mastodon API compatibility:

• PKCE (Proof Key for Code Exchange) must be optional: Because Mastodon makes PKCE optional, clients don't support it, which means other servers can't require it. PKCE (and the code_challenge parameter) ensures that an authorization code can only be exchanged by the client that initiated the OAuth request.
• Support for the client_credentials grant type: The client_credentials grant type is used to grant a client app-level access without requiring user authentication. Mastodon requires this for some of its "public" API endpoints. This necessitates a change to the database schema to allow a null account id in the client secrets table.
• Addition of a created_at timestamp property: Mastodon requires a non-standard created_at property in the body of the /oauth/token endpoint response instead of (in addition to) the standard expires_in property.
• Support for both form-encoded and JSON request bodies: This isn't a Mastodon requirement per se but popular clients clearly demand some latitude in what they send.
• WebFinger must accept requests with no resource parameter: This is honestly a bug on my part.
• Mastodon-compatible endpoints: A boatload of them. Clients expect many endpoints and don't gracefully degrade if they're not present. Really I should just implement features like pinned posts and bookmarks...

The only thing here that gives me heartburn is that PKCE is not required.

#ktistec #mastodonapi #oauth

Registered OAuth Parameters

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

#HackerNews #Registered #OAuth #Parameters #OAuth #Security #API #Development #Tech #News

If you're wondering what these documents look like, here's an example:
https://cimd-service.fly.dev/clients/bafyreidxk6lscepiy3lxtev7jag67s2taiyhk3gwazfd4khivaejsfyipq

#oauth

Built a little thing over the past ~20 hours:

A service for provisioning public Client ID Metadata Documents for use in development environments where you aren't publicly on the web.

https://cimd-service.fly.dev/

#oauth

Okay, so, I finally built that OAuth Client ID Metadata Service that I've been talking about on an off, and also verified it works with bluesky: cimd-service.fly.dev I did have to change my application_type to native to use localhost redirect URIs, which was annoying. #oauth #atproto

https://cimd-service.fly.dev/

Delegation and consent were designed to protect trust. But when incentives reward broad permissions and dark-pattern “consent,” who really benefits? In my latest post, I dig into scope creep, admin approvals, and why users are left holding the bill.

#consent #delegation #OAuth #digitalidentity

https://sphericalcowconsulting.com/2025/09/30/delegation-and-consent-who-actually-benefits/

Delegation and consent were designed to protect trust. But when incentives reward broad permissions and dark-pattern “consent,” who really benefits? In my latest post, I dig into scope creep, admin approvals, and why users are left holding the bill.

#consent #delegation #OAuth #digitalidentity

https://sphericalcowconsulting.com/2025/09/30/delegation-and-consent-who-actually-benefits/

Kanidm (written in Rust) as identity provider for #Proxmox with OAuth / OIDC.

#kanidm #idm #rust #proxmox #identitymanagement #opensource #oauth #oidc #ldap #authentik #virtualization #howto

https://gyptazy.com/blog/kanidm-with-proxmox-and-oidc-the-full-setup/

Kanidm (written in Rust) as identity provider for #Proxmox with OAuth / OIDC.

#kanidm #idm #rust #proxmox #identitymanagement #opensource #oauth #oidc #ldap #authentik #virtualization #howto

https://gyptazy.com/blog/kanidm-with-proxmox-and-oidc-the-full-setup/

I wouldn’t say this is 100% accurate but enjoy it for what it is.. a nerdy concept explained with meme cats. 🐱

#Caturday #oauth