Hashtag

#OAuth

53 posts tagged with this hashtag.

@erlend@writing.exchange · Reply to Erlend Sogge Heggen
@sl007@digitalcourage.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee

Well, after the issues with the given ActivityPub "OAuth example", I looked up
@fedify /vocab …

In all the actor types like github.com/fedify-dev/fedify/b

the following properties would be missing [if the official OAuth demo should work] :

:digitalcourage:
grant_types_supported: ['authorization_code'],

response_types_supported:
['code', 'code token'],

code_challenge_methods_supported: ['S256'],
token_endpoint_auth_methods_supported: [
'client_secret_basic'
// optional
/*, 'private_key_jwt'*/
],
token_endpoint_auth_signing_alg_values_supported: ['RS256', 'ES256'],
client_id_metadata_document_supported: true,

:digitalcourage: optional
scopes_supported and ui_locales_supported:

---

anyway:
I believe it is just misleading because of the order of querying the server and the actor description.

I would expect it to meet the spec and pull above properties from the server wide .well-known oauth and just the endpoints from the Actor …

github.com

fedify/packages/vocab/src/person.yaml at main · fedify-dev/fedify

ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

@arichtman@eigenmagic.net

I'm attempting to delegate management of service accounts/machines to Entra upstream of Keycloak. The idea is they can use client credentials flow for unattended/programmatic access, get the JWT, then exchange that token with Keycloak who trusts their issuer in the JWT authorization grant flow.

Firstly, it seems Entra *will not* issue an ID token for an App Registration (approximately an OIDC client) - not even for a VM with IMDS.

I can get an access token using client credentials flow fine, but when I present this to Keycloak for a JWT authorization grant, it bombs saying user not found. This is correct as that subject claim does not have a corresponding Keycloak user entry.

If I have to set up a user with matching ID for every Entra client, it defeats most of the benefit of delegation.

Should I be able to have Keycloak mint an access token with an unknown subject ID? I mean it does uniquely identify a principal in context of the upstream Identity Provider.

Thoughts? Ideas?

@sl007@digitalcourage.social

Verehrtes –

die API ist magisch.
Für menschy setzen wir momentan die neuen Spezifikationen um.
Zum Beispiel

:digitalcourage: Auth
https://
swicg.github.io/activitypub-api/basicprofile
with according
Metadata https://
client.dev/
and example in https://
github.com/swicg/activitypub-api

:digitalcourage: Seek
https://
swicg.github.io/activitypub-api/seekitem

:digitalcourage: Autocomplete
https://
swicg.github.io/activitypub-api/autocomplete

:digitalcourage: Server Sent Events
https://
swicg.github.io/activitypub-api/sse

:digitalcourage: HTML Discovery
swicg.github.io/activitypub-ht

swicg.github.io

ActivityPub Discovery

@sl007@digitalcourage.social
@sl007@digitalcourage.social

@hongminhee @fedify

Hey there,
this is about the new C2S specs. introducing new properties.

In swicg.github.io/activitypub-ap – the according example swicg.github.io/activitypub-ap expects the properties to be either in the /.well-known/oauth-authorization-server or in the Actor.

How can I support them in Actors created by fedify, e.g. in an ActorDispatcher ?
Maybe they should be defined in the default context …

swicg.github.io

ActivityPub API OAuth demo

@sl007@digitalcourage.social

@aaronpk

Question about the according example to swicg.github.io/activitypub-ap –
did the "server.js" file disappear?

example;
I am using it with anyway already but it might be helpful for others to mention the "server counterparts" of the used (thankfully Okta sponsored ;) `oauth4webapi` cause it's modern, uses Web API and works in all the js runtimes serverside …

swicg.github.io

Basic Profile for Social API Servers

@sl007@digitalcourage.social · Reply to FenTiger

@fentiger

just btw;
I hope, all of this will make my IndieWebCamp Brighton demo of broken registerProtocolHandlers obsolete :)
youtube.com/live/W70wd56i0Bg?t

@jaffathecake
Once I had BrowserId then the renamed Persona then WebId and now it is developer.mozilla.org/de/docs/ I suppose.
Demos fedcm-demo-rp.dev/menu
Some articles said that Firefox will ship it in 2025 / 2026 - is that still true ?

fedcm-demo-rp.dev

FedCM RP Demo - Menu

FedCM RP Demo Menu

@sl007@digitalcourage.social

Currently implementing the Federated Credential Management API
w3c-fedid.github.io/FedCM/

Flow and Benefits
corbado.com/blog/fedcm-federat

Funny Quote
„Axel Springer (Welt, Bild): German media giant with full FedCM deployment:
- 14x increase in monthly registrations after implementing FedCM“

corbado.com

FedCM (Federated Credential Management API) Overview

Learn how FedCM replaces third-party cookies with browser-mediated federated login, what browsers support it and how it fits alongside passkeys.

@mapache@hachyderm.io

I was really happy to see @benpate and @dansup exploring similar ideas at the last FediCon: reducing user friction and making onboarding to the Fediverse almost invisible.

I’ve been working along the same lines. Here’s a small example: a user can interact with a instance by simply logging in with or .

They can comment, upload images, like, boost, etc. They don’t need to know what the Fediverse is, what an instance is, or what software is running underneath.

For them, it’s just a social app.

Of course, existing Fediverse users can still connect with their Mastodon account or use their preferred Fediverse software.

Under the hood, it’s a account configured with LinkedIn/GitHub OIDC OAuth.

But to the user? Completely transparent.

I think this kind of invisible complexity is one of the ways we can make the Fediverse much more approachable without sacrificing interoperability.

@mapache@hachyderm.io

I was really happy to see @benpate and @dansup exploring similar ideas at the last FediCon: reducing user friction and making onboarding to the Fediverse almost invisible.

I’ve been working along the same lines. Here’s a small example: a user can interact with a instance by simply logging in with or .

They can comment, upload images, like, boost, etc. They don’t need to know what the Fediverse is, what an instance is, or what software is running underneath.

For them, it’s just a social app.

Of course, existing Fediverse users can still connect with their Mastodon account or use their preferred Fediverse software.

Under the hood, it’s a account configured with LinkedIn/GitHub OIDC OAuth.

But to the user? Completely transparent.

I think this kind of invisible complexity is one of the ways we can make the Fediverse much more approachable without sacrificing interoperability.

@sl007@digitalcourage.social

Yesterday I implemented for the and for Client-To-Server SignUp.

Overview client.dev/
(click the 'Explore' things for security hints)
because github.com/swicg/activitypub-a

Technically it is easy, just wanted a nice UI for Client-To-Server so any client can combine it with the webmanifest and servers for menschys, redaktor etc. will support the dark/light things and the properties theme_color and background_color as well …

PS:
For Germans the letter order in the acronym is easy to remember: It is cinnamon for the OAuth sugar [Zimt] ;)

github.com

OAuth profile · Issue #1 · swicg/activitypub-api

"As an ActivityPub API client developer, I need a standard profile of OAuth to use for authorising my app to API servers, so I don't have to create custom code for every different API server." For ...

@arichtman@eigenmagic.net

question: is there a way to allow multiple service accounts/machines to use one OIDC client?

Normally we'd go one OIDC client in confidential mode with the service account using client credentials flow - per machine access.

However, each OIDC client/service account means a new OIDC audience - and AWS has a hard limit of 100.

Direct Access grant flow is deprecated already and removed entirely I think from Oauth2.1 spec in strict mode.

Maybe we could just create users to represent the machines - but we'd have to find a way to exempt them from Realm policies like MFA etc and it still feels icky.

CC @4censord

@Edent@mastodon.social
@Edent@mastodon.social
@thisismissem@hachyderm.io

In which, Blaine Cook ( @blaine ) explains "What is OAuth?" in the framing not of standards and specifications, nor in technical terms, but instead in this framing:

> “What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design”

leaflet.pub/p/did:plc:3vdrgzr2

leaflet.pub

What is OAuth?

Wherein I [try to] answer a seemingly straightforward question: "WTF is OAuth, anyhow?"

@thisismissem.social@bsky.brid.gy

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.

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

cimd-service.fly.dev

CIMD Service - OAuth Client ID Metadata Document Service

In development, send this service your Client ID Metadata Document, and it will return you a URL to a publicly available copy.

@box464@mastodon.social

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

@box464@mastodon.social

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

@box464@mastodon.social

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

@mapache@hachyderm.io

Just had a moment of realization: even if the code compiles, it doesn't mean there aren't hallucinations lurking within.

My gen-ai agent added a URL parameter that doesn’t even exist in the OAuth spec.

Everything seemed correct, but it turned out to be just a mock.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@hollo@hollo.social

0.6.0 is coming soon!

We're putting the finishing touches on our biggest security and feature update yet. Here's what's coming:

Enhanced

  • RFC 8414 (OAuth metadata discovery)
  • RFC 7636 ( support)
  • Improved authorization flows following RFC 9700 best practices

New features

  • Extended character limit (4K → 10K)
  • Code syntax highlighting
  • Customizable profile themes
  • EXIF metadata stripping for privacy

Important notes for update

  • Node.js 24+ required
  • Updated environment variables for asset storage
  • Stronger SECRET_KEY requirements (44+ chars)

Special thanks to @thisismissem for the extensive OAuth improvements that help keep the secure and compatible! 🙏

Full changelog and upgrade guide coming with the release.

@thisismissem.social@bsky.brid.gy

Spent the past hour doing some updates to the Client ID Metadata Documents internet draft. Trying to find alignment with the Client ID Prefix internet draft and fix a few open issues. #ietf #oauth

bsky.app

Bluesky

@thisismissem.social@bsky.brid.gy

Spent the past hour doing some updates to the Client ID Metadata Documents internet draft. Trying to find alignment with the Client ID Prefix internet draft and fix a few open issues. #ietf #oauth

bsky.app

Bluesky

@johnleonard@mastodon.social
@qiita@rss-mstdn.studiofreesia.com
@qiita@rss-mstdn.studiofreesia.com
@bnewbold@social.coop

We got a blog post out summarizing our launch of OAuth for AT Protocol, and what work remains. This has been a huge project, led by Matthieu, with input from a bunch of standards folks and devs.

This tries to solve the same basic challenge that ActivityPub has, and builds on work by @thisismissem and @aaronpk at the IETF (OAuth client metadata documents). Would be great if social web protocols end up aligning on the general shape of a solution and care share code+review.

@neilmadden@infosec.exchange

Welcome to my new followers. I have taken possession of your souls, for which I am eternally grateful.

By way of , here are a few things that I am sometimes known for:

  • I wrote the book API Security in Action published by Manning. It covers a lot about modern application security, JWTs, OAuth, Kubernetes, and is secretly a tutorial on cryptography in disguise.

  • I discovered the “Psychic Signatures” critical vulnerability in Java’s implementation of ECDSA signature verification (CVE-2022-21449).

  • My blog has made its way onto Hacker News a few times.

  • I’m fairly active in the working group at the IETF. I used to be the Security Architect for ForgeRock (now part of Ping Identity).

In my past I have mostly been a software engineer. I also have a PhD in computer science, for what it’s worth, but only my bank calls me Dr and my daughter thinks I’m lying about that.

These days I run a company, Illuminated Security, that provides AppSec and Applied Cryptography consultancy, review, bespoke development, and training. I’m always happy to answer emails (eventually!) on most topics.

illuminated-security.com

illuminated

security. illuminated.