💡 [REQUEST] - support "cookie" config option for access across sub-domains

[mundanelunacy]

Summary

support for domain-wide cookies so applications that need tokens to persist across sub domains

Basic Example

1. User logs in at an app https://app.example.com with token stored at a cookie associated with ".example.com" domain
2. User able to access https://profile.example.com using token from

Drawbacks

setting cookie potentially conflicts with cookies of other libraries (?)

Unresolved questions

No response

Implementation PR

No response

Reference Issues

No response

[mundanelunacy]

Hi. Submitted a PR for review.

The additional code does the following:

1. Moved the state code out of AuthContext and into the useStorage hook
2. Added useCookieStorage to Hooks.tsx that mirrors functionality of useBrowserStorage
3. If config.storage==='cookie' then useStorage uses the state for useBrowserStorage

Optionally, config.baseDomain can be set to manually set the cookie domain.

[soofstad]

Hi,
The library will not adopt cookie support at this point.
A few reasons:

1. It's a non-recommended way of storing tokens (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-14#section-9.1)
2. It's a very uncommon for modern OAuth2 servers to use Cookies to send back tokens (do you have any examples?)
3. Cross domain/subdomain tokens kind of defeats the purpose with OAuth2. Each application should have a token that is scoped to exactly that application only. Logging in and getting new tokens for each app should not be a big hurdle as it's common to have Cookies to authenticate towards the SSO auth-server.

Only reason to implement this would be to support some rare, old?, authentication providers, who are not following best practices. Which I'm not inclined to do.
I'd rather have this library support only recommended methods and pattern.

[mundanelunacy]

Thanks for reviewing my request and I think your assessment is fair.

Cross domain/subdomain tokens kind of defeats the purpose with OAuth2. Each application should have a token that is scoped to exactly that application only. Logging in and getting new tokens for each app should not be a big hurdle as it's common to have Cookies to authenticate towards the SSO auth-server.

Apologies. I probably should have been clearer with my original request. The intent around multi-subdomain is not to support a multiple app use-case but rather, a multiple tenants under the same app use-case. let me clarify by amending my example.

1. User logs in at an app https://example.com/ with token stored at a cookie associated with ".example.com" domain
2. User able to access https://company1.example.com/ using token from 1
3. User able to access https://company2.example.com/ using token from 1

A real-life example of this would be Slack which allows a user to log into the Slack app and access data for different companies, e.g. company1.slack.com, company2.slack.com. Subdomains ensure that each company's data is properly sandboxed on the browser. It also ensures that when user switches domains, the app is effectively "refreshed" thus clearing in-memory state. As you can imagine, this use-case is quite critical in the SaaS world which needs to balance data security with user-experience.

By and large, I do agree your arguments against using cookies. Do you happen to know of any solution to the multi-tenant app use-case that could be implemented without cookies?

[soofstad]

Right, I see how cookies would make sense in this case. However, I think it would be a dangerous design from a security perspective.
I don't know exactly how they implement it. But for Slack at least, you do need to login to all workspaces separately, and then each workspace has it's own "copy" of the auth flow/system. This would work just fine with the library as it is today, simply make a different prefix for values stored in localStorage for the different "workspaces".

I might have misunderstood your scenario, but it should be possible to have the library work with multiple "workspaces", each using separate tokens towards separate resources servers.