To handle guest identities with Ory, you can use the

anonymous

authenticator provided by Ory Oathkeeper. This authenticator allows you to set up a system where unauthenticated users are treated as anonymous or guest users. Here's how you can implement this: 1. Enable the

anonymous

authenticator in your Oathkeeper configuration:

yaml authenticators:   anonymous:     enabled: true     config:       subject: guest

2. Set up an access rule that uses the

anonymous

authenticator. This rule will allow all requests to a specific route and set the subject name to the anonymous username (in this case, "guest") when no

Authorization

header is present in the HTTP request:

json {   "id": "some-id",   "upstream": {     "url": "<http://my-backend-service>"   },   "match": {     "url": "<http://my-app/some-route>",     "methods": [       "GET"     ]   },   "authenticators": [{     "handler": "anonymous"   }],   "authorizer": { "handler": "allow" },   "mutators": [{ "handler": "noop" }] }

With this configuration, requests without an

Authorization

header will be treated as guest users, with the subject set to "guest" (or whatever value you specify in the

subject

field). It's important to note that if an

Authorization

header is present, the request will be rejected, as only the anonymous authenticator is enabled for this URL. [Oathkeeper Anonymous Authenticator](https://www.ory.sh/docs/oathkeeper/pipeline/authn#anonymous) This approach allows you to handle guest identities in a secure and controlled manner within your Ory-powered application.

I apologize for the misunderstanding in my previous answer. Let me provide a more relevant response to your question about handling guest identities in Ory while tracking activities before login and persisting that information after login. Ory doesn't have a built-in feature specifically for guest identities with activity tracking. However, you can implement this functionality using a combination of Ory's identity management features and your own application logic. Here's an approach you could consider: 1. Create temporary identities: When a guest user starts interacting with your system, create a temporary identity in Ory using the admin API. You can use the [POST /admin/identities](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#metadata) endpoint to create these identities. 2. Use metadata to track activities: Ory allows you to store metadata for each identity. You can use this feature to keep track of the guest user's activities. Specifically, you can use the

metadata_public

field to store this information [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#metadata). 3. Update metadata as the user performs actions: As the guest user interacts with your system, update the metadata using the Ory API to reflect their activities. 4. Link the temporary identity to a permanent one: When the user decides to register or log in, you can link the temporary identity to their permanent identity. This can be done by copying the metadata from the temporary identity to the permanent one. Here's a general workflow you could follow: 1. When a new guest user arrives, create a temporary identity:

POST /admin/identities
{
  "schema_id": "default",
  "traits": {
    "email": "<mailto:guest_user@example.com|guest_user@example.com>"
  },
  "metadata_public": {
    "is_guest": true,
    "activities": []
  }
}

2. As the user performs actions, update the metadata:

PUT /admin/identities/{id}
{
  "metadata_public": {
    "is_guest": true,
    "activities": [
      {"action": "viewed_product", "product_id": "123"},
      {"action": "added_to_cart", "product_id": "456"}
    ]
  }
}

3. When the user registers or logs in, create a new permanent identity or update an existing one, and copy the activities from the temporary identity:

PUT /admin/identities/{permanent_id}
{
  "metadata_public": {
    "is_guest": false,
    "activities": [
      {"action": "viewed_product", "product_id": "123"},
      {"action": "added_to_cart", "product_id": "456"}
    ]
  }
}

4. After successfully linking the data, you can delete the temporary identity. Remember that this approach requires careful management of identities and proper security measures to ensure that guest activities can't be maliciously associated with the wrong permanent identity.

I apologize for the misunderstanding in my previous answer. Let me provide a more relevant response to your question about handling guest identities in Ory while tracking activities before login and persisting that information after login. Ory doesn't have a built-in feature specifically for guest identities with activity tracking. However, you can implement this functionality using a combination of Ory's identity management features and your own application logic. Here's an approach you could consider: 1. Create temporary identities: When a guest user starts interacting with your system, create a temporary identity in Ory using the admin API. You can use the [POST /admin/identities](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#metadata) endpoint to create these identities. 2. Use metadata to track activities: Ory allows you to store metadata for each identity. You can use this feature to keep track of the guest user's activities. Specifically, you can use the

metadata_public

field to store this information [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#metadata). 3. Update metadata as the user performs actions: As the guest user interacts with your system, update the metadata using the Ory API to reflect their activities. 4. Link the temporary identity to a permanent one: When the user decides to register or log in, you can link the temporary identity to their permanent identity. This can be done by copying the metadata from the temporary identity to the permanent one. Here's a general workflow you could follow: 1. When a new guest user arrives, create a temporary identity:

POST /admin/identities {   "schema_id": "default",   "traits": {     "email": "<mailto:guest_user@example.com|guest_user@example.com>"   },   "metadata_public": {     "is_guest": true,     "activities": []   } }

2. As the user performs actions, update the metadata:

PUT /admin/identities/{id} {   "metadata_public": {     "is_guest": true,     "activities": [       {"action": "viewed_product", "product_id": "123"},       {"action": "added_to_cart", "product_id": "456"}     ]   } }

3. When the user registers or logs in, create a new permanent identity or update an existing one, and copy the activities from the temporary identity:

PUT /admin/identities/{permanent_id} {   "metadata_public": {     "is_guest": false,     "activities": [       {"action": "viewed_product", "product_id": "123"},       {"action": "added_to_cart", "product_id": "456"}     ]   } }

4. After successfully linking the data, you can delete the temporary identity. Remember that this approach requires careful management of identities and proper security measures to ensure that guest activities can't be maliciously associated with the wrong permanent identity. Also, note that while this method allows you to track guest activities, it's important to comply with relevant data protection regulations and obtain necessary consents for data collection and processing. [Identity model](https://www.ory.sh/docs/kratos/manage-identities/overview) This solution isn't a built-in feature of Ory, but rather a way to leverage Ory's identity management capabilities to implement guest identity tracking. You'll need to implement most of the logic in your application to manage the creation, updating, and linking of these identities.

Based on the information provided in the knowledge sources and your question, I can offer some clarification and guidance on your issue with creating identities in Ory Kratos and using Ory Oathkeeper for authentication. First, regarding creating identities in Kratos without an

Authorization

header: You're correct that the Kratos Admin API for creating identities requires authentication. According to the [Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api), the

createIdentity

endpoint should be authenticated using an Ory Access Token. The fact that you can create identities without authentication suggests that your Kratos instance might not be properly configured for secure admin access. To secure your Kratos Admin API, you should ensure that you're using the correct authentication method. The API reference indicates that you should use the

oryAccessToken

authentication method, not client credentials. Regarding your attempt to use Oathkeeper with the

client_credentials

handler: The error you're encountering ("requested pipeline handler does not exist") suggests that Oathkeeper doesn't recognize the

client_credentials

handler. This is because Oathkeeper doesn't have a built-in

client_credentials

handler. Instead, Oathkeeper provides an

oauth2_client_credentials

authenticator that you can use for OAuth 2.0 Client Credentials flow. Here's how you can fix this: 1. Update your Oathkeeper configuration to use the correct handler:

yaml authenticators:   - handler: oauth2_client_credentials     config:       token_url: "<https://your-oauth-server.com/oauth2/token>"

2. Ensure that your OAuth2 client is properly configured. You can create a client for the Client Credentials flow using the Ory CLI:

ory create oauth2-client --project "$PROJECT_ID" \   --name "Client Credentials Demo" \   --grant-type client_credentials

3. When making requests to Oathkeeper, include your client credentials in the

Authorization

header as Basic Auth. [Oathkeeper OAuth2 Client Credentials](https://www.ory.sh/docs/oathkeeper/pipeline/authn#oauth2_client_credentials) Remember, this setup is for authenticating requests to Oathkeeper using the OAuth 2.0 Client Credentials flow. For securing the Kratos Admin API itself, you should use the authentication method specified in the Kratos documentation, which is the Ory Access Token. If you're trying to secure access to Kratos Admin API through Oathkeeper, you'll need to ensure that Oathkeeper is properly configured to forward the authenticated requests to Kratos, and that Kratos is set up to accept the authentication provided by Oathkeeper. Given the complexity of your setup, you might want to review your overall architecture and ensure that each component (Kratos, Oathkeeper, and your OAuth server) is correctly configured and integrated.