Improve documentation for development usage, prohibiting query parameters in document URLs #24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A pattern that we've seen sometimes used is to have a service generate Client ID Metadata Documents by taking in data from query parameters and transposing those into the contents of the document, this should probably be considered an anti-pattern, since it circumvents a fair few of the security properties of stable URLs for client id metadata documents.
This is noted in #23 and #12, where workarounds have tried to be developed.
For instance, for AtProto / Bluesky, they could host a
client_id.atproto.dev
service which allows you to preregistered a client for development purposes (specifying redirect_uris, scopes, etc), giving back a https URL to a document that you can use for that client.We could expand this to allow a Authorization Server to apply additional constrains on the contents of the client metadata document, based on the hostname of the document itself, e.g., only documents on
client_id.atproto.dev
hostname can include redirect URIs that are localhost URIs.