Conversation
…404 authz behavior on resource operations, and clarify that /token empty security does not allow anonymous client_credentials. Signed-off-by: Mehrn0ush <mehrnoush.vaseghi@gmail.com>
Signed-off-by: Mehrn0ush <mehrnoush.vaseghi@gmail.com>
taleodor
approved these changes
Sep 13, 2026
oej
reviewed
Sep 16, 2026
|
|
||
| Whether a server requires authentication is discovered by using it, not by configuration and not by | ||
| probing the token endpoint. The complete flow for a client that does not know in advance: | ||
| probing the token endpoint. In the OpenAPI document, resource operations list both Bearer |
Collaborator
There was a problem hiding this comment.
I think we don't have to refer to the OpenAPI document, but instead say "In TEA"...
oej
reviewed
Sep 16, 2026
| token from `/token` and retry the request once (RFC 6750 section 3.1). | ||
|
|
||
| Open servers that require no authentication on any endpoint shall not return this | ||
| status. On a mixed server, only protected endpoints return `401`; open endpoints |
Collaborator
There was a problem hiding this comment.
I am not happy with the term "mixed server". Maybe write
"On a TEA server where some data is available without authorisation, but not all, protected endpoints return"...
oej
reviewed
Sep 16, 2026
| accepted on TEA endpoints other than `/token`. | ||
|
|
||
| Resource operations declare both this requirement and an empty alternative so | ||
| that open and mixed servers are representable: a client may call without a |
Collaborator
There was a problem hiding this comment.
"open and mixed servers"... maybe
"so that a server can select which objects that require authentication"
oej
reviewed
Sep 16, 2026
| that open and mixed servers are representable: a client may call without a | ||
| token. Whether a given endpoint actually requires a token is discovered at | ||
| runtime from a `401` Bearer challenge (see `401-unauthorized`), not from this | ||
| document alone. Open servers shall ignore a presented Bearer token; mixed |
Collaborator
|
In general I don't like the term "open" and "mixed" - it's not normative language in an API spec. It's a server that doesn't require auth and thus have no authz. And a server that wants to protect some objects, but not all, with both auth and authz. Please rewrite |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
{}) security401/403on resource operations, and clarify concealing404for unauthorized access/token’s empty security requirement covers alternate client auth (mutual TLS,private_key_jwt, or credentials in the request body), not anonymousclient_credentialsThanks to @taleodor for the review feedback.
Closes #269