Skip to content

fix(endpoint-auth): use publication me when signing authorization code - #913

Open
aciccarello wants to merge 1 commit into
getindiekit:mainfrom
aciccarello:fix/me-url-redirect-resolution
Open

fix(endpoint-auth): use publication me when signing authorization code#913
aciccarello wants to merge 1 commit into
getindiekit:mainfrom
aciccarello:fix/me-url-redirect-resolution

Conversation

@aciccarello

Copy link
Copy Markdown
Collaborator

What

When signing the authorization code in consent.post, always use publication.me as the me value instead of the client-supplied me parameter.

Why

The IndieAuth spec allows clients to optionally pass a me parameter in the authorization request. Indiekit was signing whatever value the client sent directly into the authorization code and subsequent access token. If that URL differed from the configured publication.me (e.g. because it was a redirect to the canonical URL), verifyTokenValues would reject the token at query time, causing authentication to silently fail.

The IndieAuth spec explicitly permits this approach: section 5.2 says the authorization endpoint *MAY* ignore the client-supplied me entirely, and sections 5.3.2 and 5.3.3 note the returned me *MAY* differ from the URL the client provided, giving the server an opportunity to canonicalize it.

The client-supplied me is still echoed in the redirect response for backwards compatibility with older clients.

Changes

  • packages/endpoint-auth/lib/controllers/consent.js: use publication.me when signing the authorization code
  • packages/endpoint-auth/test/integration/302-consent-submit-authenticate-with-me.js: updated to use a mismatched me value and assert publication.me is in the signed code
  • packages/endpoint-auth/test/integration/302-consent-submit-authenticate.js: updated to assert publication.me is used when no me param is supplied

Fixes #911

@aciccarello

Copy link
Copy Markdown
Collaborator Author

Created this as a draft because I still need to test this locally but my brain needs sleep...

@aciccarello
aciccarello marked this pull request as ready for review August 24, 2026 15:35
@aciccarello

Copy link
Copy Markdown
Collaborator Author

Okay, I tested this and confirmed that the access token and json response contain the value from publication.me. Sparkles was able to post successfully (though it shows the original rello.me as the logged in value). Quill was able to login and shows www.ciccarello.me as the logged in user.

My only remaining question is if there could be a problem if someone else set up their publication.me slightly differently (e.g. with a trailing slash) would that cause their Indiekit to stop posting and cause confusion? I wonder if this PR should get the canonical URL before setting the me value.

Previously, the me value supplied by the client in the authorization
request was signed directly into the authorization code. If that value
differed from publication.me (e.g. a redirect URL), the issued token
would fail verification at query time.

Per the IndieAuth spec (sections 5.2, 5.3.2, 5.3.3), the authorization
server may ignore the client-supplied me and return its own canonical
profile URL. publication.me is now always used when signing the code.

The client-supplied me is still echoed back in the redirect response
for backwards compatibility.

Fixes getindiekit#911
@aciccarello
aciccarello force-pushed the fix/me-url-redirect-resolution branch 2 times, most recently from 959511f to e38b315 Compare August 24, 2026 16:00
@paulrobertlloyd
paulrobertlloyd force-pushed the main branch 2 times, most recently from 67b3847 to fa1d368 Compare August 27, 2026 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IndieAuth: normalize me URL in token response during authorization flow

1 participant