Cookie returned by /login/password

[roger-perry-gmx]

The crud test suite (and others) expect a cookie to be returned by the /login/password API call. Request some documentation on what the cookie contains and it's impact on downstream authentication.

[michielbdejong]

Roger Perry @roger-perry-gmx nov. 18 17:56

Hi Michiel, I'm trying to get these solid-crud-tests working. I notice that export CURL_RESULT=curl -i $SERVER_ROOT/login/password -d"username=$USERNAME&password=$PASSWORD" | grep Set-Cookie on https://solid-crud-tests-example-1.solidcommunity.net does return a cookie whereas my pod on https://solidcommunity.net doesn't. And my local graphMetrix server doesn't either. Can you give me any insight into what this cookie contains?

Roger Perry @roger-perry-gmx nov. 18 18:08

actually sorry, my pod https://gmxRogerPerry.solidcommunity.net does return a cookie also.

Michiel de Jong @michielbdejong nov. 18 18:10

ok
so it's working?
when you log in to your TrinPod IDP account with the goal of doing a webid-oidc dance and logging in to a solid app, how does that work? does it involve cookies?

Roger Perry @roger-perry-gmx nov. 18 19:15

no it's not working. We don't return a cookie from /login/password. The solid-auth-client puts the id_token and other stuff into session data in the browser.

Roger Perry @roger-perry-gmx nov. 18 19:20

I could return the id_token from /login/password but 'Cookie is nssidp.sid=s%3Aot9vQ4L0OUQL8nywLAFbMUr8sDi6-cPG.jKDLiUcxi2FOoU4EfyU4kZXFxiM7OTPgaJjfJbFmaNo;' that doesn't look like a JWT. i.e. id_token. Are you using the same webid-oidc authentication outlined in https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md

Michiel de Jong @michielbdejong nov. 19 07:35

Yes, but the login is usually before that. It's possible to do login during the redirect dance, but then we need to add support for that in the test suite.
So I have a question. if I log in to app1.com using redirects and my user+password, then of course app1.com can store the tokens it receives.
But then I want to use app2.com
Do I need to enter my username and password into TrinPod again? That's annoying and unusual, right? Is there a special reason why you don't maintain a cookie session at the IDP GUI?

Michiel de Jong @michielbdejong nov. 19 07:41

We can serve the cookie-less flow but please report it as a github issue at https://github.com/solid/test-suite/issues/new so it's recorded that you require that feature. That gives us a reason to prioritize it into the next sprint :)

Roger Perry @roger-perry-gmx nov. 19 23:48

Michiel we're not against maintaining a cookie session at the IDP GUI (what does IDP stand for BTW?) it's just we're not aware of what the cookie should contain. And then what its impact on downstream authentication is. I feel like we're missing a piece of a spec. somewhere. We followed the webid-oidc specification and I don't think there was any mention of storing a cookie.
Also, would you prefer me to continue this conversation on the public thread? It maybe useful to others who come along after I suppose. Thanks for your help as always.

Michiel de Jong @michielbdejong 09:16

Yes, please open an issue about it using https://github.com/solid/test-suite/issues/new and then we can discuss further there
I think your identity provider (IDP) does set a cookie after the user provides their username+password, but when I wanted to test it just now, I got a 503 error on trinpod.us

Roger Perry @roger-perry-gmx 14:16

you can try trinpod.us again. A hacker somehow shutdown the server which we're looking into.
I'll add a new issue.

Michiel de Jong @michielbdejong 14:21

thanks!

Michiel de Jong @michielbdejong 14:28

So you do a POST to https://trinpod.us/usernamePasswordValid with params username, password and client_id

Roger Perry @roger-perry-gmx 15:25

we do
to check the username password but /login/password is called perform the 'formal' login.

Michiel de Jong @michielbdejong 15:31

and what does that return?

Roger Perry @roger-perry-gmx 15:32

it currently returns the id_token. but that is our question. What should it return because the solid server seems to return a cookie

Michiel de Jong @michielbdejong 15:32

in a redirect?

Roger Perry @roger-perry-gmx 15:33

it redirects but if we detect a test script login we don't perform the redirect

Michiel de Jong @michielbdejong 15:34

ok so if you create the github issue about it then we can add support for that flow

Roger Perry @roger-perry-gmx 15:34

the origin is blank when /login/password is called from the test suite shell script

Michiel de Jong @michielbdejong 15:34

the test script should detect your login form and then "click" the login button
during the webid-oidc flow
for NSS we can do the login first, keep the cookie from that and then just send the cookie during the webid-oidc flow to prevent seeing the login prompt there
with TrinPod, the webid-oidc flow always includes a login screen
for NSS it doesn't
only if you're not cookied-in yet
your flow is valid but you need to ask the test suite to support it

Roger Perry @roger-perry-gmx 15:37

the solid-auth-client library we're using doesn't create a cookie. It does store the id_token and other data in browser local storage

Michiel de Jong @michielbdejong 15:39

correct. you don't need to use a cookie if the user is ok with logging in each time they go through webid-oidc

Roger Perry @roger-perry-gmx 15:39

and I can shut down my browser, pull it up again, and go to trinpod.us and be logged in because of the info stored in the browser local storage.

Michiel de Jong @michielbdejong 15:39

with password managers in browsers that's not such a problem
ah yes
but the first time, the login prompt for TrinPod needs to be during the webid-oidc flow

Roger Perry @roger-perry-gmx 15:40

yes

https://user-content.gitter-static.net/8a9b71656348a828884014808a8c9ec9b1b62076/68747470733a2f2f66696c65732e6769747465722e696d2f3566623535306463643733343038636534666634356335372f374365552f7468756d622f696d6167652e706e67

if I clear that highlighted local storage I would have to login again

https://user-content.gitter-static.net/07a80856835126e3caa19163a085fc69895ba104/68747470733a2f2f66696c65732e6769747465722e696d2f3566623535306463643733343038636534666634356335372f397231652f7468756d622f696d6167652e706e67

Michiel de Jong @michielbdejong 15:43

yes

Roger Perry @roger-perry-gmx 15:43

if I login with solid I get this cookie that is returned by /login/password during the test script

Michiel de Jong @michielbdejong 15:43

what does 'login with solid' mean?

Roger Perry @roger-perry-gmx 15:44

login to my pod https://gmxrogerperry.solidcommunity.net

Michiel de Jong @michielbdejong 15:44

no, TrinPod doesn't set a cookie when you log in. it just allows you to continue the webid-oidc flow
ah yes. That server runs NSS. It does set a cookie so next time you can go through the webid-oidc flow without having to provide a username/password
mind if we take this discussion to somewhere where Pete can follow?

Roger Perry @roger-perry-gmx 15:45

np yes

Michiel de Jong @michielbdejong 15:45

can i copy-paste this gitter log into a github issue?

Roger Perry @roger-perry-gmx 15:46

yes, I have created one also

Michiel de Jong @michielbdejong 15:46

ok! found it. I'll paste this conversation log into there