- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 5 May 2020 00:13:10 +0200
- To: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhKHh=eBKcLV6=MA8OHHNNdc4NZv=eASx3KgVCR48odEAg@mail.gmail.com>
Was chatting to Kingsley and Dmitri lately and I realized that quite often WebID over HTTP is authenticated via a shared secret. Namely a cookie. We realized that this is not documented anywhere. And I asked dmitri about it usage. Im just capturing the responses here. "I think all Solid servers use cookies (and store the WebID in the cookie session) as a local authentication method, in addition to TLS and OIDC. It's very convenient; the only reason it's not the main mechanism is of course, it's domain-specific." and "I don't think it's written up anywhere. I think it's because each implementation's cookie session mechanism is slightly different. But usually, it goes like: 1. When a user logs in (via username and password, or TLS, or OIDC token), you put their WebID in your session. (request.session.webId = <user's authenticated webId>) 2. In all the other requests, you just use request.session.webId directly. And the server's (Express.js, or whatever the other ones are using) session cookie store takes care of it." This actually might be one of the more common types of WebID auth. Would it be worth writing up, and should it be called: WebID + Cookie or WebID + Shared Secret?
Received on Monday, 4 May 2020 22:13:34 UTC