Swap cookie for session token for use on different domain

[abarani]

I'm trying to implement ORY Kratos in the following scenario but I'm missing something on how I can get a session token client-side.

Consider this:

• app.example.com
  Client-side SPA

• login.example.com
  Login/Registration UI

  • ORY Kratos + ORY Oathkeeper (cookie authenticator) + Login UI
  • Kratos session.cookie.domain limited to the same subdomain
  • Kratos serve.public.cors.allowed_origins set to http://login.example.com and http://app.example.com

  Cookie domain is limited to login.example.com to avoid credentials leak to api.example.com given that domain has an unrestricted CORS policy.

• api.example.com
  Backend API

  • ORY Oathkeeper (bearer token authenticator limited to some endpoints)
  • CORS allowed origins set to *

The basic login flow would be:

1. User lands on app.example.com
2. Client side SPA redirects to login.example.com for user login/registration using the browser flow.
3. On successful login login.example.com redirects the user back to app.example.com.
4. app.example.com can check for an active session by querying the login.example.com/sessions/whoami endpoint using a fetch request with credentials set to true (allowed by CORS).

At this point, is there a way to call api.example.com with a user session token?

Would it be possible to swap the user cookie token available on login.example.com for a session token to be used for calls to api.example.com protected endpoints?
I'm thinking of a token similar to the one provided in the JSON response by the flow for API clients that can be used as a bearer token for APIs on different domains.

Does this make sense or am I missing something security-wise?

[Benehiko]

Hi @abarani,

Sorry for only getting back to you now! 😰

I think i understand the use case. You have a cookie for example.com which is valid for app.example.com and login.example.com but you don't want the cookie to be used on your api.example.com so you want to transform the cookie for this sub-domain to something like a JWT?

If that's the case, maybe setting up a mutator on your oathkeeper rule to api.example.com is what you need. https://www.ory.sh/oathkeeper/docs/pipeline/mutator

[abarani]

Hi @Benehiko, no worries!

I'm aware of mutators but even assuming on using one the cookie will still be present client-side. Correct me if I'm wrong, given in this case api.example.com have an unrestricted CORS policy this opens me up to CORS attacks. If a third party makes an AJAX call to some api.example.com private endpoint it can impersonate a user without its consent. 🤔

I was thinking on protecting api.example.com with a bearer_token or a jwt authenticator. But I end up not getting how I can obtain such a token client-side with a browser login flow with Kratos.

[Benehiko]

I don't see how someone could impersonate the user because CORS is disabled. You still have a cookie set from kratos' side to a certain domain which is your domain example.com. So even if someone steals the cookie they cannot use the cookie on a different domain bar.com. Why does api.example.com need a bearer token in the first place? Why can it not just rely on oathkeeper to keep it safe?

[abarani]

I don't see how someone could impersonate the user because CORS is disabled. You still have a cookie set from kratos' side to a certain domain which is your domain example.com.

Given api.example.com have Access-Control-Allow-Origin: *, doesn't this implies that requests originating from bar.com (with credentials: 'include') will use the same cookie and thus end up being authenticated as the user logged on example.com? I can be wrong here but that's what I'm worried about.

Why does api.example.com need a bearer token in the first place?

It doesn't, it was just an alternative solution to avoid using a cookie given the assumption above is true.

Why can it not just rely on oathkeeper to keep it safe?

Even in the case of a bearer token it would still rely on Oathkeeper, just without the cookie_session authenticator but with a bearer_token or a jwt one instead.

[Benehiko]

So api.example.com will still be fine even if there is Access-Control-Allow-Origin: * since oathkeeper will first verify with kratos that the cookie is valid, which in this case coming from bar.com will just be denied, see here https://www.ory.sh/kratos/docs/debug/csrf#running-on-separate-sub-domains

[abarani]

I completely missed that page, thank you!