Open dmitrizagidulin opened 5 years ago
The consensus from the 2019-10-21 Authentication panel meeting was:
WWW-Authenticate
response header as the designated mechanism for a Resource Server to communicate which authentication method that server is using.I think the question still remains (which I forgot to bring up in the meeting):
Which attribute of the WWW-Authenticate
header do we use to communicate the authentication mechanism a server is using?
Currently, Node Solid Server is using the scope
attribute, where scope="openid webid"
means "WebID-OIDC".
Are folks ok continuing to use that attribute?
Well according to the Mozilla document on WWW-Authenticate,
WWW-Authenticate: <type> realm=<realm>
you use the type to specify the types of authentication methods allowed. They list an IANA registry of those.
My guess is that if the server wants to offer a number of different methods, it should send a number of WWW-Authenticate
headers. I am not sure where the scope
keyword comes from.
WWW-Authenticate: Bearer scope="tls webid", realm="whatever"
is improper, because it has nothing to do with OAuth2-style bearer tokens. a different auth-scheme
should have been used for this case, like
WWW-Authenticate: WebID-TLS realm="whatever"
if we're going to document deprecated legacy behavior that was deployed, putting the Bearer scope="tls webid"
in a registry somewhere is fine and all, but if we wanted to be serious about WebID-TLS again, transitioning to a different auth-scheme would be more appropriate.
while we're at it, i've always had a problem with using the Bearer
auth-scheme for the current POPToken scheme, since POPTokens, being manufactured by the client instead of being issued to the client by the RS's authorization server (#1, #12), aren't in the spirit of OAuth2 bearer tokens (that is, they're as much a "bearer token" as the Base64(username ":" password)
of HTTP Basic Auth). in an ideal world, a different auth-scheme would have been used for this too, like
WWW-Authenticate: Solid-POPToken realm="whatever"
@zenomt All good points. The scope="tls webid"
was just a historical solid-auth-client implementation note; not intending to carry it forward.
i've always had a problem with using the Bearer auth-scheme for the current POPToken scheme
DPoP draft intends to register DPoP token type for Bearer authentication scheme https://github.com/danielfett/draft-dpop/blob/master/mainmatter.md#oauth-access-token-type-registration
OAuth Access Token Type Registration
This specification registers the following access token type in the OAuth Access Token Types registry defined in [RFC6749].
- Type name: "DPoP"
- Additional Token Endpoint Response Parameters: (none)
- HTTP Authentication Scheme(s): Bearer
- Change controller: IETF
- Specification document(s): [[ this specification ]]
Also in Justin's book I've noticed use of PoP https://livebook.manning.com/book/oauth-2-in-action/chapter-15/36
HTTP POST /foo Host: example.org Authorization: PoP eyJhbGciOiJSUzI1NiJ9.eyJhdCI6ICI4dXloZ3Q2Nzg5MDQ5...
Not sure how those two registries supposed to work together
If we use authentication scheme in WWW-Authenticate
header, we can't really communicate token type. Possibly related to mentioned tendency to conflate authentication and authorization.
@elf-pavlik Ahhh yeah, ok, you're right, the DPoP draft spec does specify using 'DPoP' as the Authentication scheme.
So then we'll use as a response header:
WWW-Authenticate: DPoP realm="<optional realm>" scope="openid webid"
to indicate that the RS supports the DPoP presentation mechanism.
As both the authentication and authorization/acl systems for Solid evolve, it would be helpful to standardize on (and document) some way to inform clients as to which system (and spec version) a particular storage pod (Resource Server, in oauth2 terms) is running.
For example, currently, we use the
scope
param of theWWW-Authenticate
response header, to helpsolid-auth-client
figure out which auth mode a Solid server is running in (WebID-TLS-only, or WebID-OIDC).So, for node-solid-servers running in WebID-OIDC mode, on a 401 Unauthorized response, the server returns the following header:
WWW-Authenticate: Bearer realm="<pod serverUrl>", scope="openid webid"
The scope maps to, roughly:
openid webid
=== WebID-OIDC modetls webid
=== legacy WebID-TLS-only mode(This was included to help solid-auth-client decide on how to interface with the server).
So, we have several questions before us:
WWW-Authenticate
response header, so if we continue going with that, what should the parameter be?)The(The authorization mechanism does not need to be communicated.)WWW-Authenticate
header spec tends to conflate authentication and authorization mechanisms into one -- how do we separate the two?