#openidconnect — Public Fediverse posts

У OpenID-сервера появился второй транспорт: gRPC рядом с HTTP, на тех же маршрутах

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить. Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-* , а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом. Теперь фасадов два. Рядом с HTTP встал gRPC: те же маршруты ядра, тот же издатель, тот же реестр клиентов, то же хранилище токенов. Один и тот же токен принимается обоими транспортами и получает от них одинаковый вердикт. Про это и статья: что именно появилось, как это включить, и почему оно особенно уместно там, где gRPC уже стал ...

https://habr.com/ru/articles/1075462/

#dotnet #grpc #oauth #openidconnect #microservices

У OpenID-сервера появился второй транспорт: gRPC рядом с HTTP, на тех же маршрутах

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить. Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-* , а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом. Теперь фасадов два. Рядом с HTTP встал gRPC: те же маршруты ядра, тот же издатель, тот же реестр клиентов, то же хранилище токенов. Один и тот же токен принимается обоими транспортами и получает от них одинаковый вердикт. Про это и статья: что именно появилось, как это включить, и почему оно особенно уместно там, где gRPC уже стал ...

https://habr.com/ru/articles/1075462/

#dotnet #grpc #oauth #openidconnect #microservices

У OpenID-сервера появился второй транспорт: gRPC рядом с HTTP, на тех же маршрутах

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить. Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-* , а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом. Теперь фасадов два. Рядом с HTTP встал gRPC: те же маршруты ядра, тот же издатель, тот же реестр клиентов, то же хранилище токенов. Один и тот же токен принимается обоими транспортами и получает от них одинаковый вердикт. Про это и статья: что именно появилось, как это включить, и почему оно особенно уместно там, где gRPC уже стал ...

https://habr.com/ru/articles/1075462/

#dotnet #grpc #oauth #openidconnect #microservices

Как мы прогоняли свой OpenID-сервер через официальный conformance-suite и что он в нас нашёл

Прогон OIDF conformance-suite по redb.Identity: как настроить сьют, почему кликали вручную, и какие реальные баги он нашёл, включая утечку телефона в id_token. Мы были уверены, что profile -claims в нашем OpenID-сервере отдаются правильно. Юнит-тесты зелёные, демо-прогон зелёный, ручная проверка через curl показывала name , family_name , email , всё на месте. Потом мы прогнали сервер через официальный conformance-suite OpenID Foundation, и он показал, что телефон и адрес пользователя лежат в id_token . А id_token уходит третьим сторонам и пишется в логи как доказательство входа. То есть номер телефона пользователя ездил гораздо дальше, чем клиент вообще запрашивал. Это утечка PII, и никакой наш тест её не ловил, потому что мы не знали, что искать. Про это и статья: как устроен ...

https://habr.com/ru/articles/1073096/

#dotnet #oauth #openidconnect #security #conformance

Как мы прогоняли свой OpenID-сервер через официальный conformance-suite и что он в нас нашёл

Прогон OIDF conformance-suite по redb.Identity: как настроить сьют, почему кликали вручную, и какие реальные баги он нашёл, включая утечку телефона в id_token. Мы были уверены, что profile -claims в нашем OpenID-сервере отдаются правильно. Юнит-тесты зелёные, демо-прогон зелёный, ручная проверка через curl показывала name , family_name , email , всё на месте. Потом мы прогнали сервер через официальный conformance-suite OpenID Foundation, и он показал, что телефон и адрес пользователя лежат в id_token . А id_token уходит третьим сторонам и пишется в логи как доказательство входа. То есть номер телефона пользователя ездил гораздо дальше, чем клиент вообще запрашивал. Это утечка PII, и никакой наш тест её не ловил, потому что мы не знали, что искать. Про это и статья: как устроен ...

https://habr.com/ru/articles/1073096/

#dotnet #oauth #openidconnect #security #conformance

Как мы прогоняли свой OpenID-сервер через официальный conformance-suite и что он в нас нашёл

Прогон OIDF conformance-suite по redb.Identity: как настроить сьют, почему кликали вручную, и какие реальные баги он нашёл, включая утечку телефона в id_token. Мы были уверены, что profile -claims в нашем OpenID-сервере отдаются правильно. Юнит-тесты зелёные, демо-прогон зелёный, ручная проверка через curl показывала name , family_name , email , всё на месте. Потом мы прогнали сервер через официальный conformance-suite OpenID Foundation, и он показал, что телефон и адрес пользователя лежат в id_token . А id_token уходит третьим сторонам и пишется в логи как доказательство входа. То есть номер телефона пользователя ездил гораздо дальше, чем клиент вообще запрашивал. Это утечка PII, и никакой наш тест её не ловил, потому что мы не знали, что искать. Про это и статья: как устроен ...

https://habr.com/ru/articles/1073096/

#dotnet #oauth #openidconnect #security #conformance

🌟 LemonLDAP::NG 2.23.3 released!

ℹ️ Security fix for CVE-2026-19349 and other bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-3-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.3 released!

ℹ️ Security fix for CVE-2026-19349 and other bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-3-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.3 released!

ℹ️ Security fix for CVE-2026-19349 and other bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-3-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.3 released!

ℹ️ Security fix for CVE-2026-19349 and other bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-3-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.3 released!

ℹ️ Security fix for CVE-2026-19349 and other bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-3-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

@apps

What about OpenID Connect (OIDC) as an authentication option?

Using the Fediverse OAuth flow solely for proof of account ownership is understandable, especially with a minimal read:accounts scope and immediate token deletion. Still, OIDC would be preferable for people who already use an identity provider such as Keycloak, because authentication would be separated cleanly from access to a social-media account.

Is OIDC support planned, or being considered for a future implementation?

#OpenIDConnect #OIDC #Fediverse #fedihood

@apps

What about OpenID Connect (OIDC) as an authentication option?

Using the Fediverse OAuth flow solely for proof of account ownership is understandable, especially with a minimal read:accounts scope and immediate token deletion. Still, OIDC would be preferable for people who already use an identity provider such as Keycloak, because authentication would be separated cleanly from access to a social-media account.

Is OIDC support planned, or being considered for a future implementation?

#OpenIDConnect #OIDC #Fediverse #fedihood

@apps

What about OpenID Connect (OIDC) as an authentication option?

Using the Fediverse OAuth flow solely for proof of account ownership is understandable, especially with a minimal read:accounts scope and immediate token deletion. Still, OIDC would be preferable for people who already use an identity provider such as Keycloak, because authentication would be separated cleanly from access to a social-media account.

Is OIDC support planned, or being considered for a future implementation?

#OpenIDConnect #OIDC #Fediverse #fedihood

@apps

What about OpenID Connect (OIDC) as an authentication option?

Using the Fediverse OAuth flow solely for proof of account ownership is understandable, especially with a minimal read:accounts scope and immediate token deletion. Still, OIDC would be preferable for people who already use an identity provider such as Keycloak, because authentication would be separated cleanly from access to a social-media account.

Is OIDC support planned, or being considered for a future implementation?

#OpenIDConnect #OIDC #Fediverse #fedihood

@apps

What about OpenID Connect (OIDC) as an authentication option?

Using the Fediverse OAuth flow solely for proof of account ownership is understandable, especially with a minimal read:accounts scope and immediate token deletion. Still, OIDC would be preferable for people who already use an identity provider such as Keycloak, because authentication would be separated cleanly from access to a social-media account.

Is OIDC support planned, or being considered for a future implementation?

#OpenIDConnect #OIDC #Fediverse #fedihood

New blog post: Grocy Behind Keycloak and oauth2-proxy - A Compact SSO Integration

My Grocy instance is meant to be available to family and friends without creating yet another password graveyard. That is why authentication runs through Keycloak, while oauth2-proxy and Nginx take care of the rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Selected public direct replies may appear on the post in a privacy-conscious, minimised form.

https://blog.weindl.biz/en/2026/08/16/grocy-behind-keycloak-and-oauth2-proxy/

New blog post: Grocy Behind Keycloak and oauth2-proxy - A Compact SSO Integration

My Grocy instance is meant to be available to family and friends without creating yet another password graveyard. That is why authentication runs through Keycloak, while oauth2-proxy and Nginx take care of the rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Selected public direct replies may appear on the post in a privacy-conscious, minimised form.

https://blog.weindl.biz/en/2026/08/16/grocy-behind-keycloak-and-oauth2-proxy/

New blog post: Grocy Behind Keycloak and oauth2-proxy - A Compact SSO Integration

My Grocy instance is meant to be available to family and friends without creating yet another password graveyard. That is why authentication runs through Keycloak, while oauth2-proxy and Nginx take care of the rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Selected public direct replies may appear on the post in a privacy-conscious, minimised form.

https://blog.weindl.biz/en/2026/08/16/grocy-behind-keycloak-and-oauth2-proxy/

New blog post: Grocy Behind Keycloak and oauth2-proxy - A Compact SSO Integration

My Grocy instance is meant to be available to family and friends without creating yet another password graveyard. That is why authentication runs through Keycloak, while oauth2-proxy and Nginx take care of the rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Selected public direct replies may appear on the post in a privacy-conscious, minimised form.

https://blog.weindl.biz/en/2026/08/16/grocy-behind-keycloak-and-oauth2-proxy/

Neuer Blogbeitrag: Grocy hinter Keycloak und oauth2-proxy - Eine kompakte SSO-Integration

Meine Grocy-Instanz soll für Family & Friends erreichbar sein, aber keinen zusätzlichen Passwortfriedhof erzeugen. Deshalb läuft die Anmeldung über Keycloak; oauth2-proxy und Nginx übernehmen den Rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Ausgewählte öffentliche direkte Antworten können gekürzt und datensparsam im Blog erscheinen.

https://blog.weindl.biz/de/2026/08/16/grocy-hinter-keycloak-und-oauth2-proxy/

Neuer Blogbeitrag: Grocy hinter Keycloak und oauth2-proxy - Eine kompakte SSO-Integration

Meine Grocy-Instanz soll für Family & Friends erreichbar sein, aber keinen zusätzlichen Passwortfriedhof erzeugen. Deshalb läuft die Anmeldung über Keycloak; oauth2-proxy und Nginx übernehmen den Rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Ausgewählte öffentliche direkte Antworten können gekürzt und datensparsam im Blog erscheinen.

https://blog.weindl.biz/de/2026/08/16/grocy-hinter-keycloak-und-oauth2-proxy/

Neuer Blogbeitrag: Grocy hinter Keycloak und oauth2-proxy - Eine kompakte SSO-Integration

Meine Grocy-Instanz soll für Family & Friends erreichbar sein, aber keinen zusätzlichen Passwortfriedhof erzeugen. Deshalb läuft die Anmeldung über Keycloak; oauth2-proxy und Nginx übernehmen den Rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Ausgewählte öffentliche direkte Antworten können gekürzt und datensparsam im Blog erscheinen.

https://blog.weindl.biz/de/2026/08/16/grocy-hinter-keycloak-und-oauth2-proxy/

Neuer Blogbeitrag: Grocy hinter Keycloak und oauth2-proxy - Eine kompakte SSO-Integration

Meine Grocy-Instanz soll für Family & Friends erreichbar sein, aber keinen zusätzlichen Passwortfriedhof erzeugen. Deshalb läuft die Anmeldung über Keycloak; oauth2-proxy und Nginx übernehmen den Rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Ausgewählte öffentliche direkte Antworten können gekürzt und datensparsam im Blog erscheinen.

https://blog.weindl.biz/de/2026/08/16/grocy-hinter-keycloak-und-oauth2-proxy/

Neuer Blogbeitrag: Grocy hinter Keycloak und oauth2-proxy - Eine kompakte SSO-Integration

Meine Grocy-Instanz soll für Family & Friends erreichbar sein, aber keinen zusätzlichen Passwortfriedhof erzeugen. Deshalb läuft die Anmeldung über Keycloak; oauth2-proxy und Nginx übernehmen den Rest.

#Grocy #Keycloak #oauth2proxy #OpenIDConnect #SingleSignOn #Docker #Nginx #SelfHosting #Linux

Ausgewählte öffentliche direkte Antworten können gekürzt und datensparsam im Blog erscheinen.

https://blog.weindl.biz/de/2026/08/16/grocy-hinter-keycloak-und-oauth2-proxy/

@dansup

Thanks — that is good news, especially for Loops.

Unless I am missing something, though, Pixelfed's OIDC support is not yet operator-friendly: I could not find a documented, supported .env configuration for issuer URL, client ID, client secret, scopes and redirect URI.

So far I have had to modify configuration inside the container, which makes upgrades and reproducible Docker deployments unnecessarily painful.

A first-class .env interface — ideally documented and usable through Docker Compose secrets — would make Pixelfed's OIDC support actually practical for self-hosted instances. Is that planned as well?

#OpenIDConnect #Pixelfed #SelfHosting

@dansup

Thanks — that is good news, especially for Loops.

Unless I am missing something, though, Pixelfed's OIDC support is not yet operator-friendly: I could not find a documented, supported .env configuration for issuer URL, client ID, client secret, scopes and redirect URI.

So far I have had to modify configuration inside the container, which makes upgrades and reproducible Docker deployments unnecessarily painful.

A first-class .env interface — ideally documented and usable through Docker Compose secrets — would make Pixelfed's OIDC support actually practical for self-hosted instances. Is that planned as well?

#OpenIDConnect #Pixelfed #SelfHosting

@dansup

Thanks — that is good news, especially for Loops.

Unless I am missing something, though, Pixelfed's OIDC support is not yet operator-friendly: I could not find a documented, supported .env configuration for issuer URL, client ID, client secret, scopes and redirect URI.

So far I have had to modify configuration inside the container, which makes upgrades and reproducible Docker deployments unnecessarily painful.

A first-class .env interface — ideally documented and usable through Docker Compose secrets — would make Pixelfed's OIDC support actually practical for self-hosted instances. Is that planned as well?

#OpenIDConnect #Pixelfed #SelfHosting

@dansup

Thanks — that is good news, especially for Loops.

Unless I am missing something, though, Pixelfed's OIDC support is not yet operator-friendly: I could not find a documented, supported .env configuration for issuer URL, client ID, client secret, scopes and redirect URI.

So far I have had to modify configuration inside the container, which makes upgrades and reproducible Docker deployments unnecessarily painful.

A first-class .env interface — ideally documented and usable through Docker Compose secrets — would make Pixelfed's OIDC support actually practical for self-hosted instances. Is that planned as well?

#OpenIDConnect #Pixelfed #SelfHosting

@dansup

Thanks — that is good news, especially for Loops.

Unless I am missing something, though, Pixelfed's OIDC support is not yet operator-friendly: I could not find a documented, supported .env configuration for issuer URL, client ID, client secret, scopes and redirect URI.

So far I have had to modify configuration inside the container, which makes upgrades and reproducible Docker deployments unnecessarily painful.

A first-class .env interface — ideally documented and usable through Docker Compose secrets — would make Pixelfed's OIDC support actually practical for self-hosted instances. Is that planned as well?

#OpenIDConnect #Pixelfed #SelfHosting

@dansup

Full agree: the Fediverse needs to become easier and more familiar to use.

But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc.

For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider.

Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well?

Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much.

#OpenIDConnect #SelfHosting #Fediverse

@dansup

Full agree: the Fediverse needs to become easier and more familiar to use.

But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc.

For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider.

Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well?

Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much.

#OpenIDConnect #SelfHosting #Fediverse

@dansup

Full agree: the Fediverse needs to become easier and more familiar to use.

But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc.

For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider.

Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well?

Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much.

#OpenIDConnect #SelfHosting #Fediverse

@dansup

Full agree: the Fediverse needs to become easier and more familiar to use.

But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc.

For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider.

Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well?

Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much.

#OpenIDConnect #SelfHosting #Fediverse

@dansup

Full agree: the Fediverse needs to become easier and more familiar to use.

But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc.

For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider.

Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well?

Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much.

#OpenIDConnect #SelfHosting #Fediverse

Canop'Tips 💡 Connectez #Canopsis à votre fournisseur d'identité !

#OAuth2 et #OpenIDConnect natifs dans Canopsis :

✅ Connectez Canopsis à votre fournisseur d'identité
✅ Centralisez les accès, supprimez les mots de passe superflus
✅ Pilotez les droits depuis votre annuaire d'entreprise

Compatible GitHub, GitLab, Google et plus encore.

🔗 https://doc.canopsis.net/latest/guide-administration/administration-avancee/methodes-authentification-avancees/#authentification-oauth2-openid

#SSO #ITOps #OpenSource #Capensis

Canop'Tips 💡 Connectez #Canopsis à votre fournisseur d'identité !

#OAuth2 et #OpenIDConnect natifs dans Canopsis :

✅ Connectez Canopsis à votre fournisseur d'identité
✅ Centralisez les accès, supprimez les mots de passe superflus
✅ Pilotez les droits depuis votre annuaire d'entreprise

Compatible GitHub, GitLab, Google et plus encore.

🔗 https://doc.canopsis.net/latest/guide-administration/administration-avancee/methodes-authentification-avancees/#authentification-oauth2-openid

#SSO #ITOps #OpenSource #Capensis

Using GoToSocial as the Social Layer for Your Apps

Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.

Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

• Issuers are ActivityPub actors, so people can follow them.
• Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
• In practice, people can follow issuers and receive their badges through the social web.

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

1. A person signs in to BadgeFed or Community Credentials using an account they already have.
2. They enable social features with one setting.
3. The system provisions the social account they need.
4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

• The application owns its domain-specific interface and workflows.
• The identity provider handles the user's existing sign-in.
• GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
• Users interact from the application instead of learning a separate social client first.

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

1. Configuring GoToSocial with an external OpenID Connect provider.
2. Provisioning or connecting accounts with minimal user action.
3. Using the Mastodon-compatible API from an existing application.
4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.

Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:

#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile

Using GoToSocial as the Social Layer for Your Apps

Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.

Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

• Issuers are ActivityPub actors, so people can follow them.
• Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
• In practice, people can follow issuers and receive their badges through the social web.

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

1. A person signs in to BadgeFed or Community Credentials using an account they already have.
2. They enable social features with one setting.
3. The system provisions the social account they need.
4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

• The application owns its domain-specific interface and workflows.
• The identity provider handles the user's existing sign-in.
• GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
• Users interact from the application instead of learning a separate social client first.

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

1. Configuring GoToSocial with an external OpenID Connect provider.
2. Provisioning or connecting accounts with minimal user action.
3. Using the Mastodon-compatible API from an existing application.
4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.

Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:

#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile

Using GoToSocial as the Social Layer for Your Apps

Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.

Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

• Issuers are ActivityPub actors, so people can follow them.
• Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
• In practice, people can follow issuers and receive their badges through the social web.

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

1. A person signs in to BadgeFed or Community Credentials using an account they already have.
2. They enable social features with one setting.
3. The system provisions the social account they need.
4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

• The application owns its domain-specific interface and workflows.
• The identity provider handles the user's existing sign-in.
• GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
• Users interact from the application instead of learning a separate social client first.

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

1. Configuring GoToSocial with an external OpenID Connect provider.
2. Provisioning or connecting accounts with minimal user action.
3. Using the Mastodon-compatible API from an existing application.
4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.

Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:

#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile

Using GoToSocial as the Social Layer for Your Apps

Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.

Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

• Issuers are ActivityPub actors, so people can follow them.
• Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
• In practice, people can follow issuers and receive their badges through the social web.

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

1. A person signs in to BadgeFed or Community Credentials using an account they already have.
2. They enable social features with one setting.
3. The system provisions the social account they need.
4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

• The application owns its domain-specific interface and workflows.
• The identity provider handles the user's existing sign-in.
• GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
• Users interact from the application instead of learning a separate social client first.

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

1. Configuring GoToSocial with an external OpenID Connect provider.
2. Provisioning or connecting accounts with minimal user action.
3. Using the Mastodon-compatible API from an existing application.
4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.

Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:

#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile

Using GoToSocial as the Social Layer for Your Apps

Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.

Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

• Issuers are ActivityPub actors, so people can follow them.
• Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
• In practice, people can follow issuers and receive their badges through the social web.

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

1. A person signs in to BadgeFed or Community Credentials using an account they already have.
2. They enable social features with one setting.
3. The system provisions the social account they need.
4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

• The application owns its domain-specific interface and workflows.
• The identity provider handles the user's existing sign-in.
• GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
• Users interact from the application instead of learning a separate social client first.

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

1. Configuring GoToSocial with an external OpenID Connect provider.
2. Provisioning or connecting accounts with minimal user action.
3. Using the Mastodon-compatible API from an existing application.
4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.

Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:

#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile

via @dotnet : Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime

https://ift.tt/3IOsjnU
#NuGet #NuGetTrustedPublishing #APITokenSecurity #APIAccessSecurity #APIKeyRotation #OpenIDConnect #OIDC #SecurityNews #SupplyChainSecurity #DevOps #CI/CDSe…

via @dotnet : Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime

https://ift.tt/3IOsjnU
#NuGet #NuGetTrustedPublishing #APITokenSecurity #APIAccessSecurity #APIKeyRotation #OpenIDConnect #OIDC #SecurityNews #SupplyChainSecurity #DevOps #CI/CDSe…

via @dotnet : Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime

https://ift.tt/3IOsjnU
#NuGet #NuGetTrustedPublishing #APITokenSecurity #APIAccessSecurity #APIKeyRotation #OpenIDConnect #OIDC #SecurityNews #SupplyChainSecurity #DevOps #CI/CDSe…

via @dotnet : Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime

https://ift.tt/3IOsjnU
#NuGet #NuGetTrustedPublishing #APITokenSecurity #APIAccessSecurity #APIKeyRotation #OpenIDConnect #OIDC #SecurityNews #SupplyChainSecurity #DevOps #CI/CDSe…

via @dotnet : Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime

https://ift.tt/3IOsjnU
#NuGet #NuGetTrustedPublishing #APITokenSecurity #APIAccessSecurity #APIKeyRotation #OpenIDConnect #OIDC #SecurityNews #SupplyChainSecurity #DevOps #CI/CDSe…

Почему кнопка «Войти через VK» заняла три дня. Кейс

На первый взгляд, Social Login — одна из самых простых функций современного веб-приложения. Добавить кнопку «Войти через VK». Добавить кнопку «Войти через Яндекс». OAuth 2.0 давно стандартизирован, OpenID Connect тоже. Документации и библиотек полно. Да и AI сегодня умеет писать интеграции быстрее человека. Поэтому, когда я решил добавить VK ID и Яндекс ID в Авторизу, честно рассчитывал уложиться в один рабочий день: Свою систему знаю. OIDC знаю. Подобные интеграции раньше проектировал. Под рукой ChatGPT, Claude и AI-агенты. Что вообще может пойти не так? Спойлер: получилось почти три дня. И самой сложной частью оказался не OAuth. День первый. Самоуверенность

https://habr.com/ru/articles/1065576/

#Авторизация #Аутентификация #OAuth #openidconnect #social_login #vk_api #yandex_api #vk_id

Почему кнопка «Войти через VK» заняла три дня. Кейс

На первый взгляд, Social Login — одна из самых простых функций современного веб-приложения. Добавить кнопку «Войти через VK». Добавить кнопку «Войти через Яндекс». OAuth 2.0 давно стандартизирован, OpenID Connect тоже. Документации и библиотек полно. Да и AI сегодня умеет писать интеграции быстрее человека. Поэтому, когда я решил добавить VK ID и Яндекс ID в Авторизу, честно рассчитывал уложиться в один рабочий день: Свою систему знаю. OIDC знаю. Подобные интеграции раньше проектировал. Под рукой ChatGPT, Claude и AI-агенты. Что вообще может пойти не так? Спойлер: получилось почти три дня. И самой сложной частью оказался не OAuth. День первый. Самоуверенность

https://habr.com/ru/articles/1065576/

#Авторизация #Аутентификация #OAuth #openidconnect #social_login #vk_api #yandex_api #vk_id

Почему кнопка «Войти через VK» заняла три дня. Кейс

На первый взгляд, Social Login — одна из самых простых функций современного веб-приложения. Добавить кнопку «Войти через VK». Добавить кнопку «Войти через Яндекс». OAuth 2.0 давно стандартизирован, OpenID Connect тоже. Документации и библиотек полно. Да и AI сегодня умеет писать интеграции быстрее человека. Поэтому, когда я решил добавить VK ID и Яндекс ID в Авторизу, честно рассчитывал уложиться в один рабочий день: Свою систему знаю. OIDC знаю. Подобные интеграции раньше проектировал. Под рукой ChatGPT, Claude и AI-агенты. Что вообще может пойти не так? Спойлер: получилось почти три дня. И самой сложной частью оказался не OAuth. День первый. Самоуверенность

https://habr.com/ru/articles/1065576/

#Авторизация #Аутентификация #OAuth #openidconnect #social_login #vk_api #yandex_api #vk_id

🌟 LemonLDAP::NG 2.23.1 released!

ℹ️ Certificate based LDAP authentication and some bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-1-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.1 released!

ℹ️ Certificate based LDAP authentication and some bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-1-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.1 released!

ℹ️ Certificate based LDAP authentication and some bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-1-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.1 released!

ℹ️ Certificate based LDAP authentication and some bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-1-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

🌟 LemonLDAP::NG 2.23.1 released!

ℹ️ Certificate based LDAP authentication and some bug fixes

➡️ https://projects.ow2.org/view/lemonldap-ng/lemonldap-ng-2-23-1-is-out/

@ow2 @PerlRakuFoundation

#IAM #SSO #CAS #SAML #OpenIDConnect #OpenSource #LogicielLibre #Perl

أصدرت Linkwarden 2.15 تحديثًا ضخمًا لتطبيقها المحمول، مضيفًا ميزات قراءة وتعليق جديدة مثل التمييز بأربعة ألوان، وإرفاق الملاحظات، وعرض مخصص لها. كما يتيح حفظ الروابط للاستخدام دون اتصال، وتخصيص الخط وحجمه ولون الخلفية. وشمل التحديث تحسينات خلفية كبيرة، وتقليل استهلاك الذاكرة، وصغر حجم صورة Docker، ودعم OpenID Connect، مع التركيز على تعزيز الأمان.

#Linkwarden #OpenIDConnect

SimpleHelp Vulnerability Exploited to Deliver Novel Malware

A critical vulnerability in SimpleHelp's remote monitoring software, rated a perfect 10 in severity, was exploited by attackers to masquerade as trusted technicians and deploy brand-new malware across customer networks. This flaw allowed hackers to bypass authentication and gain unauthorized access with ease.

https://osintsights.com/simplehelp-vulnerability-exploited-to-deliver-novel-malware?utm_source=mastodon&utm_medium=social

#Cve202648558 #RemoteMonitoringAndManagement #Rmm #OpenidConnect #AuthenticationBypass

SimpleHelp vulnerability exposes servers to rogue remote support accounts

A critical vulnerability in SimpleHelp, known as CVE-2026-48558, lets hackers create rogue remote support accounts and gain privileged access to servers, allowing them to execute scripts and wreak havoc on your system. This gaping security hole enables unauthenticated attackers to bypass multi-factor authentication and log in as a…

https://osintsights.com/simplehelp-vulnerability-exposes-servers-to-rogue-remote-support-accounts?utm_source=mastodon&utm_medium=social

#Cve202648558 #OpenidConnect #Oidc #MfaBypass #Vulnerability

One Open-source Project Daily

Simple, unobtrusive authentication for Node.js.

https://github.com/jaredhanson/passport

#1ospd #opensource #express #nodejs #oauth #oauth2 #openid #openidconnect #passport #saml

One Open-source Project Daily

Simple, unobtrusive authentication for Node.js.

https://github.com/jaredhanson/passport

#1ospd #opensource #express #nodejs #oauth #oauth2 #openid #openidconnect #passport #saml