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>
|
|
||
| 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 |
There was a problem hiding this comment.
I think we don't have to refer to the OpenAPI document, but instead say "In TEA"...
| 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 |
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"...
| 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 |
There was a problem hiding this comment.
"open and mixed servers"... maybe
"so that a server can select which objects that require authentication"
| 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 |
There was a problem hiding this comment.
Removed. That paragraph now describes a server with no authentication vs one that protects some objects but not all.
|
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 |
Describe servers by whether they require authentication or protect only some objects, and frame the client flow as In TEA rather than OpenAPI.
|
Rewrote throughout auth/readme.md and the OpenAPI security/401 prose. Terminology is now “server that requires no authentication” and “server that protects some objects,” matching auth vs authz as you described. Also renamed the former “Mixed servers” section accordingly. |
3 participants
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