The knowledge sources provided do not contain specific information on how to convert an access token from an OAuth2 flow into a session token in Ory. However, they do provide information on how to use an access token to authenticate various operations in Ory's API, such as introspecting an OAuth2 token, getting an OAuth2 login request, and getting an OAuth2 client. For example, to perform the operation of introspecting an OAuth2 token, you must be authenticated by means of an

oryAccessToken

([source](https://www.ory.sh/docs/reference/api)). If you want to check the status of a session, you can use the Ory Session Token at the

<http://127.0.0.1/sessions/whoami>

endpoint ([source](https://www.ory.sh/docs/kratos/self-service/flows/user-login#api-clients)). For more specific information on how to convert an access token into a session token, you may need to refer to more detailed documentation or resources.

Yes, you can use Ory Oathkeeper to check if you have a session or access token. For session checking, Ory Oathkeeper uses the

Cookie Session Authenticator

which points to Ory Kratos'

/sessions/whoami

API. It uses the

ory_kratos_session

cookie to identify if a request contains a session or not ([source](https://www.ory.sh/docs/kratos/guides/zero-trust-iap-proxy-identity-access-proxy#ory-oathkeeper-identity-and-access-proxy)). Here is an example of how it's configured in the Oathkeeper configuration file:

yaml authenticators:    cookie_session:    enabled: true    config:    check_session_url: <http://kratos:4433/sessions/whoami>    preserve_path: true    extra_from: "@this"    subject_from: "identity.id"    only:    - ory_kratos_session

For access token checking, you can define access rules for your API endpoints in Ory Oathkeeper. For example, you can specify that a valid OAuth 2.0 Access Token is required to access certain resources ([source](https://www.ory.sh/docs/ecosystem/projects#ory-oathkeeper)). However, the specific method to check an access token would depend on the type of access token and the specific access rules you have defined.

Sure, here is an example of an

oauth2_introspection

authenticator configuration for Ory Oathkeeper:

yaml # Some Access Rule: access-rule-1.yaml   id: access-rule-1   # match: ...   # upstream: ...   authenticators:    - handler: oauth2_introspection      config:        introspection_url: <https://my-website.com/oauth2/introspection>        scope_strategy: exact        required_scope:        - photo        - profile        target_audience:        - example_audience        trusted_issuers:        - <https://my-website.com/>        pre_authorization:          enabled: true          client_id: some_id          client_secret: some_secret          scope:          - introspect          token_url: <https://my-website.com/oauth2/token>        token_from:          query_parameter: auth-token          # or          # header: Custom-Authorization-Header          # or          # cookie: auth-token        introspection_request_headers:          x-forwarded-proto: https          x-foo: bar        retry:          max_delay: 300ms          give_up_after: 2s

This configuration is for an access rule in Ory Oathkeeper that uses the

oauth2_introspection

authenticator. The authenticator checks if the request has a Bearer Token in the Authorization Header or in a different header or query parameter specified in the configuration. It then uses OAuth 2.0 Token Introspection to check if the token is valid and if the token was granted the requested scope ([source](https://www.ory.sh/docs/oathkeeper/pipeline/authn#oauth2_introspection-configuration)).

To configure Ory Oathkeeper to get identity data from the token subject, you can use the

id_token

mutator. This mutator transforms the authentication information (such as the subject) into a signed JSON Web Token, specifically an OpenID Connect ID Token. Here is an example of how to configure the

id_token

mutator in the Oathkeeper configuration file:

yaml # Global configuration file oathkeeper.yml   mutators:    id_token:    # Set enabled to true if the authenticator should be enabled and false to disable the authenticator. Defaults to false.    enabled: true    config:    issuer_url: <https://my-oathkeeper/>    jwks_url: <https://fetch-keys/from/this/location.json>    # jwks_url: file:///from/this/absolute/location.json    # jwks_url: file://../from/this/relative/location.json    ttl: 60s    claims: '{"aud": ["<https://my-backend-service/some/endpoint>"],"def": "{{ print .Extra.some.arbitrary.data }}"}'

In this configuration, the

id_token

mutator is enabled and the issuer URL and JWKS URL are set. The

claims

field allows you to customize the ID Token claims and supports Go Templates ([source](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#id_token-configuration)). Please note that the actual configuration may vary depending on your specific use case and setup.

To get the identity data, including metadata from an access token received from the Ory network in Oathkeeper, you can use the

oauth2_introspection

authenticator. This authenticator checks if the request has a Bearer Token in the Authorization Header or in a different header or query parameter specified in the configuration. It then uses OAuth 2.0 Token Introspection to check if the token is valid and if the token was granted the requested scope. Here is an example of how to configure the

oauth2_introspection

authenticator in the Oathkeeper configuration file:

yaml authenticators:   oauth2_introspection:     enabled: true     config:       introspection_url: <https://my-website.com/oauth2/introspection>       scope_strategy: exact       required_scope:       - photo       - profile       target_audience:       - example_audience       trusted_issuers:       - <https://my-website.com/>       pre_authorization:         enabled: true         client_id: some_id         client_secret: some_secret         scope:         - introspect         token_url: <https://my-website.com/oauth2/token>       token_from:         query_parameter: auth-token       introspection_request_headers:         x-forwarded-proto: https         x-foo: bar       retry:         max_delay: 300ms         give_up_after: 2s

This configuration is for an access rule in Ory Oathkeeper that uses the

oauth2_introspection

authenticator. The authenticator checks if the request has a Bearer Token in the Authorization Header or in a different header or query parameter specified in the configuration. It then uses OAuth 2.0 Token Introspection to check if the token is valid and if the token was granted the requested scope ([source](https://www.ory.sh/docs/oathkeeper/pipeline/authn#oauth2_introspection-configuration)). The introspection endpoint will return a JSON response that includes the identity data and metadata associated with the access token. The specific fields returned in the response will depend on your specific OAuth2 setup and the scopes associated with the access token.

Sure, you can use the

introspectOAuth2Token

method from the Ory Client to introspect an access token. Here is an example of how you can do this using a curl command:

bash curl -X POST <https://my-website.com/oauth2/introspection> \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Bearer {ORY_API_KEY}' \ -d 'token={access_token}'

In this command, replace

<https://my-website.com/oauth2/introspection>

with your introspection URL,

{ORY_API_KEY}

with your actual Ory API key, and

{access_token}

with the access token you want to introspect. The introspection endpoint will return a JSON response that includes the identity data and metadata associated with the access token. The specific fields returned in the response will depend on your specific OAuth2 setup and the scopes associated with the access token. Please note that the actual command may vary depending on your specific setup and the API you are using ([source](https://www.ory.sh/docs/hydra/guides/oauth2-token-introspection)).

To get identity traits and metadata, you need to include the appropriate scopes in your OAuth2 client configuration. The specific scopes required will depend on the identity data you want to access. For example, in Ory, the

email

and

profile

scopes are commonly used to access identity traits. The

email

scope is used to include the email in the ID token claims, and the

profile

scope is used to access various traits associated with a user, such as username, website, and updated_at ([source](https://www.ory.sh/docs/oauth2-oidc/openid-connect-claims-scope-custom)). Here is an example of how to configure these scopes in the OAuth2 client:

yaml # OAuth2 client configuration client_id: your-client-id client_secret: your-client-secret redirect_uris: - <https://your-redirect-uri> grant_types: - authorization_code - refresh_token response_types: - code - id_token scope: "openid offline_access email profile"

In this configuration, replace

your-client-id

,

your-client-secret

, and

<https://your-redirect-uri>

with your actual client ID, client secret, and redirect URI. Please note that the actual scopes and configuration may vary depending on your specific setup and the identity data you want to access. For more information, you may need to refer to more detailed documentation or resources.

The knowledge sources provided do not specify a particular scope for accessing

metadata_public

in Ory. The scopes in OAuth2 typically include

openid

,

profile

,

email

,

address

, and

phone

, but these are standard scopes defined by the OpenID Connect specification and may not directly correspond to the

metadata_public

field. In Ory, the specific scopes required and the data they provide access to can be customized based on your needs. If

metadata_public

is a custom field you've defined in your Ory setup, you may need to define a custom scope that provides access to this field. For more specific information on how to access

metadata_public

with a specific scope, you may need to refer to more detailed documentation or resources.

Sure, here is an example of how you can configure the

hydrator

mutator in Ory Oathkeeper to get the identity from the token subject using the Ory network admin/identities endpoint:

yaml # Some Access Rule: access-rule-1.yaml   id: access-rule-1   # match: ...   # upstream: ...   authenticators:    - handler: oauth2_introspection      config:        introspection_url: <https://my-website.com/oauth2/introspection>        scope_strategy: exact        required_scope:        - photo        - profile        target_audience:        - example_audience        trusted_issuers:        - <https://my-website.com/>        pre_authorization:          enabled: true          client_id: some_id          client_secret: some_secret          scope:          - introspect          token_url: <https://my-website.com/oauth2/token>        token_from:          query_parameter: auth-token        introspection_request_headers:          x-forwarded-proto: https          x-foo: bar        retry:          max_delay: 300ms          give_up_after: 2s   mutators:    - handler: hydrator      config:        api:          url: <http://ory-kratos-admin/identities/{{introspection.sub}}>

In this configuration, the

hydrator

mutator is configured to make a request to the Ory network admin/identities endpoint with the subject from the token introspection as a path parameter. The

hydrator

mutator will then add the response from this request to the HTTP headers, body, or URL parameters of the upstream request ([source](https://www.ory.sh/docs/oathkeeper/pipeline/mutator#hydrator)). Please note that the actual configuration may vary depending on your specific use case and setup.

Yes, you can define more than one authenticator in the Access Rule in Ory Oathkeeper. The first authenticator that's able to handle the credentials will be consulted and other authenticators will be ignored. Here is an example:

json {  "authenticators": [  {  "handler": "a"  },  {  "handler": "b"  },  {  "handler": "c"  }  ] }

In this example, if handler

a

is able to handle the provided credentials, then handler

b

and

c

will be ignored. If handler

a

can't handle the provided credentials but handler

b

can, then handler

a

and

c

will be ignored. Handling the provided credentials means that the authenticator knows how to handle, for example, the

Authorization: basic

header. It doesn't mean that the credentials are valid! If a handler encounters invalid credentials, then other handlers will be ignored too ([source](https://www.ory.sh/docs/oathkeeper/pipeline/authn)).

Sorry @polite-finland-81696, I seem to be having a bit of trouble. Don't worry though, I've pinged my support folks and they will try to fix me up! 🧑‍💻 Perhaps try again in 5mins?

Sorry @polite-finland-81696, I seem to be having a bit of trouble. Don't worry though, I've pinged my support folks and they will try to fix me up! 🧑‍💻 Perhaps try again in 5mins?

Sorry @polite-finland-81696, I seem to be having a bit of trouble. Don't worry though, I've pinged my support folks and they will try to fix me up! 🧑‍💻 Perhaps try again in 5mins?

Sorry @polite-finland-81696, I seem to be having a bit of trouble. Don't worry though, I've pinged my support folks and they will try to fix me up! 🧑‍💻 Perhaps try again in 5mins?

Sorry @polite-finland-81696, I seem to be having a bit of trouble. Don't worry though, I've pinged my support folks and they will try to fix me up! 🧑‍💻 Perhaps try again in 5mins?