Based on the provided knowledge sources, there doesn't appear to be a way to query what organization an email domain belongs to without using a workspace API key. The information available indicates that operations related to organizations, including querying them, require authentication using a workspace API key. According to the [Ory API Reference](https://www.ory.sh/docs/reference/api), operations related to organizations, such as listing, creating, getting, updating, and deleting organizations, all require authentication using the

oryWorkspaceApiKey

method. The [Docs > Kratos > B2B Single Sign-On & SAML](https://www.ory.sh/docs/kratos/organizations) section also mentions that managing organizations, whether through the Ory Console or API, requires a workspace API key for authentication. Furthermore, the [Docs > Concepts > Ory Network API Keys](https://www.ory.sh/docs/concepts/personal-access-token#authorizing-ory-network-workspace-admin-apis) emphasizes that workspace API keys are necessary for authorizing privileged operations, including those related to B2B SSO organizations within a project. Given this information, it appears that a workspace API key is required for any operations involving organizations, including querying which organization an email domain belongs to. There is no mention of a public API or method to perform this query without authentication.

Based on the information provided in the knowledge sources, it appears that there's a mismatch between the client authentication method supported by the OAuth 2.0 client and the method being used in the request. Let me explain this in more detail: 1. Client Authentication Methods: The OAuth 2.0 specification supports different methods for client authentication at the token endpoint. The two methods mentioned in your question are: - `client_secret_basic`: The client ID and secret are sent in the HTTP Authorization header. - `client_secret_post`: The client ID and secret are sent in the POST body. 2. Client Configuration: According to the error message, the OAuth 2.0 client is configured to support the

client_secret_basic

method. This means the client expects the credentials to be sent in the Authorization header. 3. Request Method: However, the error suggests that the request is using the

client_secret_post

method, which means the credentials are being sent in the POST body. To resolve this issue, you have two options: 1. Change the request method: Modify your token request to use the

client_secret_basic

method. This involves sending the client ID and secret in the Authorization header. Example:

curl -X POST '<http://127.0.0.1:4444/oauth2/token>' \    -H 'Authorization: Basic base64(client_id:client_secret)' \    -H 'Content-Type: application/x-www-form-urlencoded' \    --data-urlencode 'grant_type=client_credentials'

2. Update the client configuration: Alternatively, you can update the OAuth 2.0 client configuration to support the

client_secret_post

method. You can do this using the Ory CLI:

ory update oauth2-client --token-endpoint-auth-method client_secret_post

Or via the API:

curl --request PUT '<http://127.0.0.1:4445/admin/clients/{client_id}>' \    --header 'Content-Type: application/json' \    --data-raw '{      "token_endpoint_auth_method": "client_secret_post"    }'

For more details on configuring OAuth 2.0 clients, you can refer to the [Ory documentation on managing OAuth 2.0 clients](https://www.ory.sh/docs/hydra/guides/oauth2-clients). Remember, it's crucial to ensure that the client authentication method used in the request matches the method configured for the client to successfully complete the OAuth 2.0 client credentials grant flow.

Based on the knowledge sources provided, there isn't a specific built-in "trial" mechanism in Ory Network that directly implements time-limited access for users or groups. However, you can leverage some of Ory's features to implement this functionality yourself. Here are a few approaches you could consider: 1. Use Ory Permissions: Ory Permissions (formerly Keto) allows you to define fine-grained access control rules. You could create a custom relationship that includes an expiration time for trial users. You would need to implement the logic to check and enforce this expiration in your application. [Ory Permissions documentation](https://www.ory.sh/docs/keto/reference/ory-permission-language) provides information on how to define and use custom relationships. 2. Leverage OAuth2 token expiration: While not directly a "trial" mechanism, you could use short-lived access tokens for trial users. You would need to implement the logic in your application to deny refresh token requests after the trial period ends. The [Ory documentation on token expiration](https://www.ory.sh/docs/hydra/guides/client-token-expiration) explains how to configure token lifespans. 3. Custom claims in ID tokens: You could add a custom claim to the ID token that indicates the trial expiration date. Your application would need to check this claim and enforce the expiration. 4. Implement in your application logic: Store the trial expiration information in your application's database and check it when processing requests. You would use Ory for authentication and authorization, but handle the trial logic in your application. It's important to note that implementing a trial mechanism would require custom development on your part, as Ory Network doesn't provide this as an out-of-the-box feature. If you need more specific guidance or have additional requirements for your trial mechanism, you might want to reach out to Ory support. As mentioned in the [Personal Data Storage with Ory Network](https://www.ory.sh/personal-data-storage/#reach-out) document, they encourage users to contact them with questions or feedback about features and use cases.

Certainly! I can provide an example of how to implement a trial function using relationships in Ory Permissions (formerly Keto). This example will use the Ory Permission Language (OPL) to define the necessary relationships and permissions. Here's a basic implementation:

typescript import { Namespace, Context } from "@ory/keto-namespace-types"  class User implements Namespace {}  class Application implements Namespace {   related: {     trial_users: User[]   }    permits = {     access: (ctx: Context): boolean => {       const now = new Date();       const trialStart = new Date(ctx.subject.metadata.trial_start);       const trialEnd = new Date(trialStart.getTime() + (30 * 24 * 60 * 60 * 1000)); // 30 days trial        return this.related.trial_users.includes(ctx.subject) && now < trialEnd;     }   } }

In this example: 1. We define a

User

namespace to represent users. 2. We define an

Application

namespace with a

trial_users

relationship to represent users who have access to the trial. 3. We create an

access

permission that checks if the user is in the

trial_users

relationship and if their trial period is still active. To use this in your application: 1. When a user starts a trial, you would create a relationship:

ory create relationship Application:your_app_id#trial_users@User:user_id

2. You would also need to store the trial start date as metadata for the user. This isn't directly supported in Ory Permissions, so you'd need to store this in your application's database or use a custom claim in the user's ID token. 3. When checking if a user has access, you would make a permission check:

ory is allowed User:user_id access Application your_app_id

This implementation has some limitations: 1. It doesn't automatically remove expired trial users. You'd need to implement a separate process to clean up expired relationships. 2. It relies on storing the trial start date outside of Ory Permissions. For a more robust solution, you might consider combining this with other Ory features or implementing part of the logic in your application. Remember, this is a basic example and may need to be adapted based on your specific requirements and the full capabilities of your Ory Network setup. For more detailed information on using Ory Permissions and the Ory Permission Language, you can refer to the [Ory Permission Language specification](https://www.ory.sh/docs/keto/reference/ory-permission-language#examples) and the [guide on creating a permission model](https://www.ory.sh/docs/keto/modeling/create-permission-model).