Repository navigation
Rethink authentication configuration #672
Description
Activity
I see that currently those 3 mechanisms allow authenticated requests:
- client certificates
- bearer tokens
- cookies
Few questions come to my mind:
- which use cases require use of cookies and can not use barer tokens instead?
- in which order those mechanisms apply when server expects authenticated request?
- when one mechanism gets exchanged for another one, for example
- cookie gets set based on client cert
- cookie gets set based on bearer token
- bearer token gets issued based on client cert
Remark by @timbl that we should differentiate between AJAX requests and regular browser requests. For the latter, cookie-based sessions are very useful.
Reacted by Andreas KuckartzI understand that we can rely on bearer token only when we make requests with Fetch API in javascript. Regular browser requests only support client certificates and cookies.
I think in most scenarios RDF Sources would get requested with Fetch API, but Non-RDF Sources which IRIs get used directly as values of
srcattribute in HTML elements would end up as regular requests.
In that case, WebID-TLS could trigger cert selection popup if media resource embedded in the page requires it. How WebID-OICD supposed to handle those cases if browser doesn't have active cookie session with the origin of that embedded media resource?I'd also like to check if Service Worker can intercept regular browser requests for media resources and give control back to developer over how requests are performed, possibly also to include bearer token or request Federated Credential solid/solid#142 if needed for WebID-OICD flow.
Reacted by Andreas KuckartzHow WebID-OICD supposed to handle those cases if browser doesn't have active cookie session with the origin of that embedded media resource?
We'd need some scripting to detect this and help us with that.
I'd also like to check if Service Worker can intercept regular browser requests for media resources
That might be possible to a certain extent! I am interested in porting solid-auth-client to a worker, so I can run it in the background (as we currently do for our query client, for instance).
Reacted by Andreas KuckartzWe'd need some scripting to detect this and help us with that.
I started separated issue to discuss Service Workers including possibility of using them in such scenarios. solid/solid#143
Reacted by Andreas Kuckartz@dmitrizagidulin But no session is created (and no cookie is generated) when the RP makes a request to some third Resource Server. So, when I sign into a distributed Twitter type app which fetches messages from a dozen different resource servers, I only have a session with my WebID's IDP, and the app itself. But not with any of those resource servers.
Based on above, server not acting as IdP (OICD Issuer) would never use cookies. Given that, I think for general role of Resource Server (dataset origin) we should never rely on cookie based sessions and for authenticated request only use:
- client certificates
- bearer tokens
This way it would not matter if client interacts with datasets on same origin as user's IdP or datasets on all other origins.
Thanks for putting this together!
Will there also be a sub issue related to the initialization of a server for the first time. ie running
bin/solid initPossibly some of this will change too. Is it covered in an existing sub issue?
@melvincarvalho Added to the list above
Reacted by Melvin Carvalho and Andreas KuckartzThe proposed changes sound quite large and intrusive, are they? Is this something we should aim for 5.0.0, or is it rather something that should be addressed in a later release where they can be first addressed at an architectural level?
Let's aim for 6.0.0 (it's not assigned to 5.0.0).
Reacted by Kjetil KjernsmoReading through the initial summary, is part of the thinking to make the configuration extensible so that an admin could pass their own OIDC provider into the
ResourceAuthenticatorinitialization such that tokens from 3rd parties could be accepted as valid?
Right now, the server supports two different auth modes, confusingly named
auth: "tls"andauth: "oidc", even though that doesn't cover exactly what they do. The main problem is that this one setting gives the impression that both methods are mutually exclusive, whereas they are not.Discussions such as #667, #671, nodeSolidServer/solid-auth-client#44, solid/solid#138, nodeSolidServer/oidc-auth-manager#20 show that there is a need for more clarity, and a better configuration option.
This issue tracks general progress and will act as a tracker for multiple sub-issues.
Here are the steps we need to take in my opinion:
initgenerator to create the right configauthconfig sectionFeedback welcome.