To get the JWT public key from the Ory network, you can use the standard endpoint

/.well-known/jwks.json

which contains the public keys for verifying ID tokens and JWT access tokens. This endpoint is exposed by default for each Ory Network project. The URL format is as follows:

https://{project.slug}.<http://projects.oryapis.com/.well-known/jwks.json|projects.oryapis.com/.well-known/jwks.json>

Replace

{project.slug}

with your specific project slug. You can use a simple HTTP GET request to retrieve the keys. Here is an example using curl:

bash curl https://{project.slug}.<http://projects.oryapis.com/.well-known/jwks.json|projects.oryapis.com/.well-known/jwks.json>

If you are using the Ory Proxy, the public key is available at

/.ory/proxy/jwks.json

. You can retrieve it with the following command:

bash curl -sk https://<proxy-host>/.ory/proxy/jwks.json

Replace

<proxy-host>

with your specific proxy host. Please note that these operations do not require authentication. Sources: - [Ory Documentation](https://www.ory.sh/docs/hydra/jwks#the-role-of-well-knownjwksjson) - [Ory Proxy Documentation](https://www.ory.sh/docs/guides/cli/proxy-and-tunnel#use-ory-proxy-with-json-web-tokens) - [Hydra API Reference](https://www.ory.sh/docs/hydra/reference/api)

To get the JWT public key from the Ory network that was created with

ory create jwk

, you can use the Ory API's

getJsonWebKeySet

method. This method retrieves a JSON Web Key Set stored in ORY Hydra. Here is the endpoint:

GET /admin/keys/{set}

Replace

{set}

with the JSON Web Key Set ID that you used when creating the key with

ory create jwk

. Please note that to perform this operation, you must be authenticated by means of the

oryAccessToken

. Here is an example using curl:

bash curl -H "Authorization: Bearer {oryAccessToken}" <https://your-ory-instance.com/admin/keys/{set}>

Replace

{oryAccessToken}

with your actual Ory access token and

<http://your-ory-instance.com|your-ory-instance.com>

with your actual Ory instance URL. Sources: - [Ory API Reference](https://www.ory.sh/docs/reference/api) - [Ory CLI Documentation](https://www.ory.sh/docs/cli/ory-create-jwk#ory-create-jwk)

The

.toSession

method in Ory's API is used to check who the current HTTP session belongs to. It uses the HTTP headers in the GET request to determine who is authenticated and returns a session object in the body or 401 if the credentials are invalid or no credentials were sent. However, the

.toSession

method does not directly include user permissions in the JWT. The session object returned by this method typically includes the user ID and other session-related information, but not specific user permissions. If you want to include user permissions in a JWT, you would typically need to customize the token generation process to include the necessary permissions in the token's payload. This might involve querying your user database or another service to retrieve the user's permissions when the token is being generated. Unfortunately, the provided knowledge sources do not include specific information on how to customize the token generation process in Ory to include user permissions in the JWT. For more detailed guidance, you may want to refer to the [Ory documentation](https://www.ory.sh/docs/) or seek advice from the Ory community or support channels.

To use Ory Oathkeeper to convert sessions to JWTs, you need to use the ID Token Mutator. Here are the steps: 1. The ID Token Mutator takes all the available session information and puts it into a JSON Web Token (JWT). 2. The JWT is signed using an RS256 key. You can generate the RS256 key yourself by running the following command:

bash oathkeeper credentials generate --alg RS256 > id_token.jwks.json

3. To verify the JWT, you can use the public key provided by Ory Oathkeeper's JWKS API. The endpoint for this is

<http://127.0.0.1:4456/.well-known/jwks.json>

. 4. You also need to enable the ID Token Mutator in your Oathkeeper configuration. Here is an example of how to do this:

yaml mutators:     id_token:       enabled: true       config:         issuer_url: <http://127.0.0.1:4455/>         jwks_url: file:///etc/config/oathkeeper/id_token.jwks.json         claims: |           {             "session": {{ .Extra | toJson }}           }

In this configuration, the

issuer_url

is the URL of the Ory Oathkeeper instance, and the

jwks_url

is the file path to the JWKS file you generated earlier. Please note that this is a basic example and your actual configuration may need to be more complex depending on your specific requirements. Sources: - [Zero Trust with Access Proxy guide](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#id-token-mutator) - [Oathkeeper Mutator Documentation](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token)

Ory Network provides a low-latency, globally distributed system with appropriate caching, cache invalidation, and other optimizations. You don't need to worry about caching the permission checks in your application. Incorrect caching can lead to security vulnerabilities, so it's best to avoid it altogether. Here are some best practices for handling permissions: 1. Don't cache permission checks: Ory Network handles caching for you, so you don't need to cache permission checks in your application. 2. Perform permission checks in every critical path of the application: Anytime an action is taken that requires a permission check, make sure to perform that check using Ory Permissions. This includes creating, reading, updating, and deleting resources. 3. Use fine-grained permissions: Ory Permissions allows you to define fine-grained permissions, which can help you enforce the principle of least privilege. This means that you can give users the permissions they need, and nothing more. 4. Audit permissions: It's important to review and audit permissions to ensure that users just have the access they need. Use Ory Permissions' powerful query capabilities to find and fix any permissions that are no longer necessary. Source: [Ory Documentation](https://www.ory.sh/docs/keto/guides/simple-access-check-guide#best-practices)

Ory Network uses a caching mechanism called Edge Sessions to ensure the lowest possible latency on the critical-path Check Session API, which includes the

toSession

and

/sessions/whoami

endpoints. With Edge Sessions enabled, the system uses smart caching strategies to validate sessions at edge nodes that are reachable within 100ms for 95% of the world's population. The caching strategy is as follows: - If the session credentials are unknown, the cache is bypassed. - If the session credentials are known and cached, the cache is served immediately and refreshed in the background. - If the session credentials are known and cached, the cache respects the

Cache-Control: max-age=60

header. - If the user updates their profile or adds another authentication factor, the session is refreshed in the cache automatically. As for the cost of cached calls, the provided knowledge sources do not specify whether cached calls are billed or not. For detailed information about the pricing, you should refer to the [Ory Pricing page](https://www.ory.sh/pricing) or contact Ory directly. Source: [Ory Documentation](https://www.ory.sh/docs/concepts/cache)

Ory Network does not explicitly mention caching for permissions in the provided knowledge sources. However, it does emphasize that you should not cache permission checks in your application. This is because incorrect caching can lead to security vulnerabilities. Instead, Ory Network provides a low-latency, globally distributed system with appropriate caching, cache invalidation, and other optimizations. This means that Ory Network handles caching for you, ensuring that your application is secure and that users have access to the resources they need. For every critical path in your application, you should perform permission checks using Ory Permissions. This includes actions such as creating, reading, updating, and deleting resources. Source: [Ory Documentation](https://www.ory.sh/docs/keto/guides/simple-access-check-guide#best-practices)

To see how many calls you've made to the permissions API, you can check your usage on the Ory Console. Here's how: 1. Navigate to the Ory Console at

<https://console.ory.sh/>

. 2. After logging in, navigate to the workspace usage and billing page. You can do this either through the workspace menu on the top left, or by navigating to the workspace settings page and then selecting Usage and billing from the sidebar. 3. Here, you should be able to see your usage details, including the number of permission checks (API calls to the permissions API). Please note that usage invoices are only available for workspaces on a paid subscription plan. The usage is always invoiced monthly, even if the plan is paid annually. For the current billing period, the usage is generated as a preview and refreshed at most every six hours. Source: [Ory Console Documentation](https://www.ory.sh/docs/console/usage-billing#ory-console-ui)

The Ory Oathkeeper's ID Token Mutator can be used to transform authentication information into a signed JSON Web Token (JWT). However, the provided knowledge sources do not include specific information on how to use the Oathkeeper's ID Token Mutator to call the Ory Permissions API, get the user's permissions, and then add them to the JWT. Typically, you would need to create a custom mutator or hydrator that makes a call to the Ory Permissions API, retrieves the user's permissions, and then includes them in the JWT. This would likely involve writing custom code and may require a good understanding of the Ory ecosystem and the programming language you are using. For more detailed guidance, you may want to refer to the [Ory Oathkeeper Mutator Documentation](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token) and the [Ory Permissions API Documentation](https://www.ory.sh/docs/keto/reference/api). You may also want to seek advice from the Ory community or support channels.