Ability to have a managed sessions so users don't have to worry about token management and we can build client side JS libraries to support "drop in" auth.
What
If a developer turns on and configures custom hostnames they can now enable managed sessions. This works by setting a session cookie on the custom hostnamed version of auth to the parent domain (e.g, auth.example.com sets session cookie on example.com and subdomains).
Customer apps can the request information or make api calls directly from their clients without having to manage tokens, credentials, etc.
NOTE: choosing to use managed sessions means that you cannot use OAuth callback and this doesn't mean you can authenticate in third-party app (you still need to redirect to CNAMEd auth app to complete the auth flow)
How
allow CNAME of auth app (not passport app)
setting frame ancestor CSP policy to protect auth from being embedded
setup KV for storing session ids with metadata like device, access urn, ttl
picassobanana
commented
6 months ago
Why
Ability to have a managed sessions so users don't have to worry about token management and we can build client side JS libraries to support "drop in" auth.
What
If a developer turns on and configures custom hostnames they can now enable managed sessions. This works by setting a session cookie on the custom hostnamed version of auth to the parent domain (e.g, auth.example.com sets session cookie on example.com and subdomains).
Customer apps can the request information or make api calls directly from their clients without having to manage tokens, credentials, etc.
NOTE: choosing to use managed sessions means that you cannot use OAuth callback and this doesn't mean you can authenticate in third-party app (you still need to redirect to CNAMEd auth app to complete the auth flow)
How
Notes