Description
During the authorization flow, the me value supplied by the client is used as-is when signing the access token, without following HTTP redirects to find the canonical URL.
This means if a user's me URL is a redirect (e.g. https://rello.me → https://www.ciccarello.me), the issued token will contain the pre-redirect URL. When that token is later introspected by authenticate(), verifyTokenValues compares the token's me against the publication's configured me and finds a mismatch, causing authentication to fail.
Expected behaviour
The me URL should be ignored and publication.me always returned. This is consistent with the IndieAuth spec which notes that the me param doesn't have to be used and is primarily for multi-user servers.
The authorization endpoint MAY use the provided me query component as a hint of which user is attempting to sign in, and to indicate which profile URL the client is expecting in the resulting profile URL response or access token response. This is specifically helpful for authorization endpoints where users have multiple supported profile URLs, so the authorization endpoint can make an informed decision as to which profile URL the user meant to identify as. Note that from the authorization endpoint's view, this value as provided by the client is unverified external data and MUST NOT be assumed to be valid data at this stage. If the logged-in user doesn't match the provided me parameter by the client, the authorization endpoint MAY either ignore the me parameter completely or display an error, at the authorization endpoint's discretion.
The key change is that the me value in the token response SHOULD be the canonical value (not whatever was passed in per the IndieAuth spec. This is already checked by the token endpoint but as noted in #825 this is not currently checked in the token response but checked in the token validation (which only occurs if there's no cookie).
The resulting profile URL MAY be different from the URL provided to the client for discovery. This gives the authorization server an opportunity to canonicalize the user's URL, such as correcting http to https, or adding a path if required. See Differing User Profile URLs for security considerations client developers should be aware of.
Steps to reproduce
- Have a
me URL that redirects to another URL (e.g. https://rello.me → https://www.ciccarello.me)
- Configure indiekit with the destination URL as
publication.me
- Authenticate with the redirecting URL via a Micropub client (e.g. Omnibear)
- The client receives a token with
me: https://rello.me
- Subsequent requests with that token fail authentication because
me does not match the configured publication URL
Additional context
Discovered while investigating #825.
Description
During the authorization flow, the
mevalue supplied by the client is used as-is when signing the access token, without following HTTP redirects to find the canonical URL.This means if a user's
meURL is a redirect (e.g.https://rello.me→https://www.ciccarello.me), the issued token will contain the pre-redirect URL. When that token is later introspected byauthenticate(),verifyTokenValuescompares the token'smeagainst the publication's configuredmeand finds a mismatch, causing authentication to fail.Expected behaviour
The
meURL should be ignored and publication.me always returned. This is consistent with the IndieAuth spec which notes that themeparam doesn't have to be used and is primarily for multi-user servers.The key change is that the
mevalue in the token response SHOULD be the canonical value (not whatever was passed in per the IndieAuth spec. This is already checked by the token endpoint but as noted in #825 this is not currently checked in the token response but checked in the token validation (which only occurs if there's no cookie).Steps to reproduce
meURL that redirects to another URL (e.g.https://rello.me→https://www.ciccarello.me)publication.meme: https://rello.memedoes not match the configured publication URLAdditional context
Discovered while investigating #825.