Block cookie auth from non-subdomains, but allow all other auth from everywhere

[RubenVerborgh]

#834 overreached, since it applied the cross-domain cookie ban from #793 to all auth methods, not just the cookie-base auth method.

The implementation currently contains a level-breaking hack, where the general module needs to know about the OIDC logout paths. A proper fix would require a more intense refactoring, where cookie-based auth is seen as a third method in addition to WebID-TLS and WebID-OIDC, not as part of either.

Also, we should note that this fix (as did #834) allows any third party app to log the user out without their explicit permission if they happen to know the user's pod.

[kidehen]

@RubenVerborgh ,

Re

Also, we should note that this fix (as did #834) allows any third party app to log the user out without their explicit permission if they happen to know the user's pod.

I assume that only applies to WebID-OIDC mode servers rather than both WebID-OIDC or WebID-TLS mode servers. Basically, if one deployed a TLS-mode pod said issue wouldn't exist, which is what I would expect.

[RubenVerborgh]

I assume that only applies to WebID-OIDC rather than both WebID-OIDC and WebID-TLS.

Yes.

[RubenVerborgh]

Actually, @kidehen, I realize that this issue is not a server-side issue but an OIDC client issue.

At the moment, the logout request is being authenticated through a cookie. And we normally block cross-origin cookies for security purposes, but now explicitly make an exception for logout requests.

However, why don't we authenticate the logout request with an OIDC bearer token? Then none of this is necessary. Or is this against OIDC spec?

[RubenVerborgh]

@kidehen I copied this code from @smalinin, but I actually don't think that goodbye is necessary in this exception list (although it doesn't really hurt). The user needs to be authenticated for logout, but not for goodbye, right?

[kidehen]

Hmm..
I would suggest the workaround as is for now, we know it works (and it doesn't hurt in the worst case).

/cc @smalinin @cblakeley

[dmitrizagidulin]

Authenticating with a cookie is a temporary hack. The spec requires the token to be used. This is implemented in oidc-op, btw.

(apologies for brevity, on mobile)

[RubenVerborgh]

Thanks @dmitrizagidulin, this is what I suspected. Anything stopping solid-auth-client from using that oidc-op code? We use logout on oidc-rp right now.

[dmitrizagidulin]

Yeah, solid-auth-client just requires refactoring to use oidc-rp’s logoutRequest() method instead of logout(). (and send a POST to the resulting url)

[kidehen]

@dmitrizagidulin,

We are now back to oidc-op, which @cblakeley has been working on. Thus, can we triangulate back to the issue and PR combo that put an end to this issue.

/cc @RubenVerborgh @smalinin @kjetilk

[dmitrizagidulin]

@kidehen Not quite, we’re not back to oidc-op. I was just saying that the correct fix has been already added to oidc-op and -rp. And the last step required is the refactor to auth client.

[kidehen]

@dmitrizagidulin ,

How do I compute

Not quite, we’re not back to oidc-op. I was just saying that the correct fix has been already added to oidc-op and -rp. And the last step required is the refactor to auth client. ?

Where is the correct fix bearing in mind the oidc-op and -rp fixes you mention?

My setup:

OIDC Relying Party (RP)

npm list @solid/oidc-rp
solid-server@4.1.4 /home/smalinin/node-solid-server-oidc
├─┬ @solid/oidc-auth-manager@0.16.4 (git+https://github.com/OpenLinkSoftware/oidc-auth-manager.git#045a256fb75040d8206bf0bb7ad034b725260dad)
│ └─┬ @solid/solid-multi-rp-client@0.4.4
│   └── @solid/oidc-rp@0.8.0  deduped
├─┬ @solid/solid-auth-oidc@0.3.0
│ └── @solid/oidc-rp@0.8.0 
└─┬ solid-auth-client@2.2.6 (git+https://github.com/OpenLinkSoftware/solid-auth-client.git#a68512b8a73780c00a0b1a7dedcf041f439e4b9a)
  └── @solid/oidc-rp@0.8.0  deduped

and

OIDC Provider

npm list @solid/oidc-op
solid-server@4.1.4 /home/smalinin/node-solid-server-oidc
├─┬ @solid/oidc-auth-manager@0.16.4 (git+https://github.com/OpenLinkSoftware/oidc-auth-manager.git#045a256fb75040d8206bf0bb7ad034b725260dad)
│ └── @solid/oidc-op@0.4.0  deduped
└── @solid/oidc-op@0.4.0 

I can only conclude that "refactoring" in the solid-auth-client is WIP, so our workaround stays until that work is completed, right?

/cc @smalinin @cblakeley @RubenVerborgh @kjetilk @justinwb

[kidehen]

Confirming authorization informed by ACLs is still working, based on current workaround.

Evidence:

1. https://drive.verborgh.org/public/RWWCrewQA/RWWCrew%20Meeting%20by%20%40kidehen/ -- entries created across panes using one of my many WebIDs

[dmitrizagidulin]

@kidehen

Where is the correct fix bearing in mind the oidc-op and -rp fixes you mention?

I'm referring to PRs nodeSolidServer/oidc-op#7 and nodeSolidServer/oidc-rp#6

so our workaround stays until that work is completed, right?

That seems reasonable to me. We can roll back the cookie changes in this PR afterwards, when the auth client refactor is merged.

[kjetilk]

OK, sounds good. @RubenVerborgh please merge at your discretion, we can then roll a release ASAP.

[RubenVerborgh]

Thanks all!

[RubenVerborgh]

solid-auth-client fix so that cookies are no longer used in nodeSolidServer/solid-auth-client#70