I've finally mounted a composed docker system with kratos for user management with an angular SPA UI and oathkeeper for policy enforcement behind a caddy proxy. For same domain (ie. protected resource on the same domain as kratos) works fine: 1. GET

protected.main.localhost/

2. proxy calls

oathkeeper.internal/

3. oathkeeper with cookie authenticator calls

kratos.internal/

4.

kratos.internal/

redirects to

account.main.localhost/login?redirect_to=...

5.

account.main.localhost/

starts a browser based flow with

kratos.main.localhost/

6. User enters credentials, OK, redirect back to

protected.main.localhost/

7. this time

oathkeeper.internal/

finds a session cookie on the request, so it lets the request to continue Now, i want to use kratos user DB in a third-party app on a different domain,

app.acme.localhost

. But since third-party cookies won't be sent, oathkeeper won't receive cookies set by kratos on the domain

.main.localhost

- so apparently the cookie authenticator is a no go. What is the correct way to configure oathkeeper/kratos for this use-case?

This (third party) is exactly where kratos ends. With third parties you have to make use of oidc/oauth2, so hydra, which you have to integrate with kratos. In addition you'll need to extend your oathkeeper rules or add new ones to cope with tokens in addition to kratos session cookies/tokens

What i was looking into, but wanted to make sure not to overcomplicate unnecessarily the architecture before moving on. If i'm getting the idea right, it should be 1. GET

app.acme.localhost

2. proxy forwards request to

oathkeeper.internal/

3. no session found (should be in oauth/oidc token format?), redirects to OIDC login? 4. ??? 5.

app.acme.localhost

initiates an auth flow with

hydra.main.localhost

(could be using a BFF pattern) Won't go further with steps now, since i have some doubts on step 3/4

Actually, the following way: 1. GET

app.acme.localhost

2.

app.acme.localhost

executes the authorization code grant flow (using hydra) and receives an access token 3.

app.acme.localhost

accesses whatever resources at

protected.main.localhost

and adds the received access token to the request. 4. proxy in front of

protected.main.localhost

calls

oathkeeper.internal

5. oathkeeper with jwt or introspection authenticator verifies either the jwt or calls the introspection endpoint from hydra to get information about the user represented by the token 6. if 5 was ok, oathkeeer allows the request to be forwarded to

protected.main.localhost

resource

Can't Oathkeeper be configured separately for a resource with an authenticator using OIDC, pointing to

hydra.main.localhost

?

Oathkeeper cannot drive oidc flows

meaning it can't initiate it, right? I think i saw a

jwt

and various

oauth

type authenticators. Aren't those meant to be used in this scenario?

No. Only for verification purposes.

so in my caddy proxy, if

oathkeeper

denies a request with 401, it`s the proxy that should redirect to a URL to get a oauth token*, and after getting one, retry the request setting it in header/query param so

oauthkeeper

can introspect/verify with

kratos

*could be the

ory/hydra-login-consent-node

... it`s the proxy that should redirect to a URL to get a oauth token ...

Yes

could be the

ory/hydra-login-consent-node

No. That is the "frontend" for hydra (glue code with your idp, here kratos)

so there is one server/step missing to orchestrate ("drive") the obtaining the token part?

proxy

->

?

->

hydra-node

->

hydra

->

kratos

You're very welcome