To pass on user IDs from Ory Oathkeeper to your backend API, you can use the

header

mutator in Oathkeeper. This mutator allows you to add arbitrary headers to the upstream request. You can use it to add a header that contains the user's ID. Here is an example of how to use the

header

mutator:

json {    "id": "some-id",    "upstream": {    "url": "<http://my-backend-service>"    },    "match": {    "url": "<http://my-app/api/<.*>>",    "methods": ["GET"]    },    "authenticators": [    {    "handler": "anonymous"    }    ],    "authorizer": {    "handler": "allow"    },    "mutators": [    {    "handler": "header",    "config": {    "headers": {    "X-User": "{{ print .Subject }}",    "X-Some-Arbitrary-Data": "{{ print .Extra.some.arbitrary.data }}"    }    }    }    ]   }

In this example, the

X-User

header will contain the user's ID (

.Subject

), and this header will be included in the request to your backend service. Your backend service can then extract the user ID from the

X-User

header and use it to create relationships in Ory Keto via the Relationships API. For creating relationships in Ory Keto, you can use the Write APIs. These APIs offer multiple ways to insert and delete relationships. Here is an example of how to use the Write API to create a relationship:

json {   "namespace": "files",   "object": "file1",   "relation": "owner",   "subject": "user1" }

In this example, a relationship is created between the object

file1

and the subject

user1

in the

files

namespace with the relation

owner

. Sources: - [Oathkeeper Mutator Header](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#header-access-rule-example) - [Keto API Overview](https://www.ory.sh/docs/keto/concepts/api-overview#change-relationships)

Yes, you're correct. For security reasons, your backend API should not be directly exposed to the public internet. Instead, it should be protected behind an API Gateway or a similar security layer. Ory Oathkeeper can act as such a security layer. It can authenticate, authorize, and mutate incoming HTTP(s) requests. It uses a set of access rules to determine how requests to your backend API should be handled. In addition, Ory Hydra serves APIs via two ports: a public port (default 4444) and an administrative port (default 4445). The public port can and should be exposed to public internet traffic, while the administrative port should not be exposed to public internet traffic. If you want to expose certain endpoints, such as the

/clients

endpoint for OpenID Connect Dynamic Client Registry, you can do so but you need to properly secure these endpoints with an API Gateway or Authorization Proxy. Sources: - [Ory Oathkeeper](https://www.ory.sh/docs/oathkeeper/) - [Ory Hydra](https://www.ory.sh/docs/hydra/self-hosted/production#exposing-administrative-and-public-api-endpoints)

Yes, it would be prudent for the backend API to validate the

X-User

header value. This is an important step to ensure that the user ID received is valid and corresponds to an existing user in your system. The exact method of validation will depend on your specific application and user management system. For example, you might check if the user ID exists in your user database, or if it matches a certain format. Remember, security is about layers, and each check adds an additional layer of security. While Ory Oathkeeper does a great job in authenticating and authorizing requests, it's always a good practice to add additional checks in your backend service. Please note that these checks should not replace the authentication and authorization provided by Ory Oathkeeper, but rather supplement it. Also, be aware that any checks you add should not expose sensitive user information or lead to potential security vulnerabilities, such as User Enumeration. In summary, while it's not strictly necessary to validate the

X-User

header in your backend API (since Ory Oathkeeper has already authenticated the request), doing so can add an additional layer of security to your application.