-
Notifications
You must be signed in to change notification settings - Fork 3
Prohibit following redirects whilst fetching Client Metadata #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -34,6 +34,7 @@ normative: | |||||||||
| RFC6749: | ||||||||||
| RFC6819: | ||||||||||
| RFC7591: | ||||||||||
| RFC8259: | ||||||||||
| RFC8414: | ||||||||||
| RFC9700: | ||||||||||
|
|
||||||||||
|
|
@@ -151,22 +152,37 @@ the client to the user in an authorization consent screen, for example the | |||||||||
| client name and logo. | ||||||||||
|
|
||||||||||
| The authorization server SHOULD fetch the document indicated by the `client_id` | ||||||||||
| to retrieve the client registration information. | ||||||||||
|
|
||||||||||
| ## Client Metadata | ||||||||||
|
|
||||||||||
| The client metadata document URL is a JSON document containing the metadata | ||||||||||
| of the client. The client metadata values are the values defined in | ||||||||||
| the OAuth Dynamic Client Registration Metadata OAuth Parameters registry | ||||||||||
| to retrieve the client registration information. A successful response MUST use | ||||||||||
| the 200 OK HTTP status code, have the content type of `application/json` or a more | ||||||||||
| specific content type that conforms to `application/<AS-defined>+json`, and be a | ||||||||||
| valid JSON object {{RFC8259}}. The authorization server MUST treat all other | ||||||||||
| HTTP status codes and content types as an error response. The authorization | ||||||||||
| server MUST NOT automatically follow HTTP redirects when retrieving the client | ||||||||||
| registration information. | ||||||||||
|
|
||||||||||
| If authorization server encounters an error response when retrieving the client | ||||||||||
| registration information, the authorization server SHOULD abort the | ||||||||||
| authorization request. The authorization server MAY use error responses to | ||||||||||
| inform their security policies. | ||||||||||
|
Comment on lines
+163
to
+166
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do not think this is needed. |
||||||||||
|
|
||||||||||
| ## Client Metadata Document | ||||||||||
|
|
||||||||||
| A Client Metadata Document is a JSON document {{RFC8259}} containing the client | ||||||||||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a better way to say this than "JSON document" since that's not exactly a defined term? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The term you are looking for is "JSON text" https://datatracker.ietf.org/doc/html/rfc8259#section-1.2 ... containing an "object".... or directly https://datatracker.ietf.org/doc/html/rfc8259#section-4 "A Client Metadata Document is a JSON object as described in {{Section 4 of RFC8259}}." |
||||||||||
| registration information for the client. The properties of the Client Metadata | ||||||||||
| Document are the values defined in the OAuth Dynamic Client Registration | ||||||||||
| Metadata OAuth Parameters registry | ||||||||||
| <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata>. | ||||||||||
|
|
||||||||||
| The client metadata document MUST contain a `client_id` property whose value | ||||||||||
| MUST match the URL of the document using simple string comparison as | ||||||||||
| defined in [RFC3986] Section 6.2.1. | ||||||||||
|
|
||||||||||
| The client metadata document MAY define additional properties in the response. | ||||||||||
| The client metadata document MAY also be served with more specific content types | ||||||||||
| as long as the response is JSON and conforms to `application/<AS-defined>+json`. | ||||||||||
|
|
||||||||||
| The client metadata document MUST be served with a 200 OK HTTP status code, | ||||||||||
| have the content type of `application/json` or a more specific content type that | ||||||||||
| conforms to `application/<AS-defined>+json`, and be a valid JSON object | ||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this language comes from something to do with content types, basically trying to say that |
||||||||||
| {{RFC8259}}. | ||||||||||
|
|
||||||||||
| As there is no way to establish a shared secret to be used with client metadata | ||||||||||
| documents, the following restrictions apply on the contents of the | ||||||||||
|
|
@@ -196,14 +212,8 @@ To enable developers to author applications on their machines, without exposing | |||||||||
|
|
||||||||||
| A Client ID Metadata Document Service is a web service through which developers can acquire a stable URL to a Client ID Metadata Document. This service MAY expire clients from time to time, and MAY require developers to provide additional information about the client being developed. | ||||||||||
|
|
||||||||||
|
|
||||||||||
| By providing at least one Client ID Metadata Document Service, an authorization server can enable developers to create applications, and still indicate to non-technical people that the client that they are about to authorize is currently under-development and may not be trustworthy or secure. | ||||||||||
|
|
||||||||||
| ## Metadata Discovery Errors | ||||||||||
|
|
||||||||||
| If fetching the metadata document fails, the authorization server SHOULD abort the | ||||||||||
| authorization request. | ||||||||||
|
Comment on lines
-202
to
-205
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is implied by the error response section. |
||||||||||
|
|
||||||||||
| ## Metadata Caching | ||||||||||
|
|
||||||||||
| The authorization server MAY cache the client metadata it discovers at the | ||||||||||
|
|
||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this redundant? Or at worst contradictory? Above we say
successful response MUST use.. and be a valid JSON objectbut here only a SHOULD?