Hi there, since a few weeks i plan to access my pod ;-) This oauth thing is driving me crazy.
To get the AccessToken i think i've to post something like that:
curl --location --request POST 'https://solidcommunity.net/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id=https://naturzukunft.solidcommunity.net/profile/card#me' \
--data-urlencode 'code=xxxxxxxxxxx' \
--data-urlencode 'client_secret=https://naturzukunft.solidcommunity.net/profile/card#me' \
--data-urlencode 'redirect_uri=http://localhost:8080'
and the code seems to be the authorization token.
That i think can be fetched with somethiong like that:
curl --location --request POST 'https://solidcommunity.net/authorize' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'response_type=code' \
--data-urlencode 'client_id=https://naturzukunft.solidcommunity.net/profile/card#me' \
--data-urlencode 'scope=create' \
--data-urlencode 'redirect_uri=localhost:8080/callback'
The second one says: 401 Unauthorized
do you want to save my weekend?
Thanks Fredy
aveltens use the client_id you got from client registration
aveltens also I am not sure if x-www-form-urlencoded will work. I had success POSTing application/json
aveltens redirecting to the Login page
aveltens oh, and scope should be openid
aveltens at least this is what worked for me. But I am no expert in Solid-OIDC, so anybody please feel free to correct or complement me
so if i understand you correct, that it is:
curl --location --request POST 'https://solidcommunity.net/authorize' \
--header 'Content-Type: application/json' \
--data-raw '{
"response_type":"code",
"client_id":"2ee6e1aebef0f7491462242faa45fd0b",
"scope":"openid",
"redirect_uri":"https://app.example/oidc_callback"
}
'
with this request here, i get the login HTML site. That is maybe correct, but i don't want to run in the browser ;-(
Proposing agenda item for the next meeting (today): https://github.com/WICG/WebID/issues/41#issuecomment-716446481 (see rest of the repo for details on WICG's WebID re authentication space). There is a TPAC breakout session on WICG/WebID: https://www.w3.org/2020/10/TPAC/breakout-schedule.html#webid .
As said, we (Solid CG) should identify areas where they may be synergy with the WICG looking into "WebID".
I tweaked the GitHub actions as part of the pull request.
The name collision is significant but a temporary issue if addressed soon. This is where communities acting in good faith goes a long way.
A much bigger and a long-term issue is communities addressing similar problems/needs re Web identifiers (and linked identities) and authentication - at least the rough bits right now if we compare their notes with ours. Soon enough it will affect authorization, payments...
This is all part of a broad and complicated discussion involving different communities with their preferred stuff. And, it is in the camp of age old issues eg. identity in the browser, formats, .. through OWP.
I suggest that we identify areas where synergy may - should! - be possible. Components/mechanisms that UAs can handle natively or provide good support would be preferable than using/injecting separate libraries/systems. (Related obvious example: it doesn't take much to know that browsers natively handling RDF parsing/serializing would make things heck of a lot simpler/better for developers and end-users than...)
Perhaps we need an issue on this in solid/specification or solid/authentication-panel ... but first I suggest that we review their WIP, come up with the overlap/delta.. and discuss with WICG. Relatively simple: Could/Will they use RWW/Solid's WebID? Same same but different? (Their examples seems to be using domains or emails, and seems to have room for DIDs... so WebID can also be part of the picture) Complex: authentication.. what does that entail for the Solid ecosystem? Obviously we don't want to be in a situation where browsers natively do something similar to what Solid proposes. If sufficiently compatible, it'll be easy to transition I presume, but my concern is that we should not end up in that situation, if we take the right steps, now.