bland-finland-95044
03/07/2024, 3:52 PMchilly-king-10285
03/07/2024, 3:52 PMchilly-king-10285
03/07/2024, 3:52 PMbland-finland-95044
03/07/2024, 8:05 PMchilly-king-10285
03/07/2024, 8:05 PMchilly-king-10285
03/07/2024, 8:05 PMbland-finland-95044
03/07/2024, 8:09 PMchilly-king-10285
03/07/2024, 8:09 PMchilly-king-10285
03/07/2024, 8:09 PMbland-finland-95044
03/07/2024, 8:29 PMchilly-king-10285
03/07/2024, 8:29 PMchilly-king-10285
03/07/2024, 8:30 PMbland-finland-95044
03/07/2024, 8:32 PMchilly-king-10285
03/07/2024, 8:32 PMchilly-king-10285
03/07/2024, 8:32 PM"Ory OAuth2 Example"
with the name of your project. bash ory create project --name "Ory OAuth2 Example" project_id="{set to the project ID from output}"
3. Create an OAuth2 client: Use the Ory CLI to create a new OAuth2 client. This client will be used for M2M communication. Replace "Client Credentials Demo"
with the name of your client. bash ory create oauth2-client --project "$project_id" \ --name "Client Credentials Demo" \ --grant-type client_credentials
4. Export the ID and secret of the created client: The ID and secret of the client are needed for authentication. Replace {set to CLIENT ID from output}
and {set to CLIENT SECRET from output}
with the actual client ID and secret from the output. bash client_id="{set to CLIENT ID from output}" client_secret="{set to CLIENT SECRET from output}"
5. Start the Client Credentials Grant: Use the Ory CLI to start the Client Credentials Grant. This will authenticate the client and grant it an access token. bash ory perform client-credentials \ --client-id="$client_id" \ --client-secret="$client_secret" \ --project "$project_id"
6. Perform token introspection: Use the Ory CLI to perform token introspection. This will give you the details of the access_token
. bash # Export 'access_token' access_token="{set to ACCESS TOKEN from output}" # Perform token introspection ory introspect token $access_token --project "$project_id"
Please note that this is a general guide and the specific steps may vary depending on your use case and configuration. For more detailed instructions, you should refer to the [Ory documentation](https://www.ory.sh/docs/getting-started/ory-network-oauth2#client-credentials-grant).bland-finland-95044
03/07/2024, 8:44 PMchilly-king-10285
03/07/2024, 8:44 PMchilly-king-10285
03/07/2024, 8:45 PMhandler
and config
. The handler
defines the handler to be used (for example, noop
), and config
configures the handler. The configuration keys vary per handler and can be defined in the global configuration file or per access rule. Here's an example of how you might define an authenticator in an Access Rule: json { "authenticators": [ { "handler": "noop", "config": {} } ] }
2. Authorization: After successful authentication, Ory Oathkeeper proceeds to the authorization step. Access Rules can check permissions. For example, to secure an API that requires certain privileges, you would configure the authorizer to check if the user ID from the authentication step has the necessary permission or role. Ory Oathkeeper supports a variety of authorizers. 3. Mutation: The Access Rule can add session data to the HTTP request that it forwards to the upstream API. For example, the mutator could add X-User-ID: the-user-id
to the HTTP headers or generate a JWT with session information and set it as Authorization: Bearer the.jwt.token
. For more detailed information, you can refer to the [Ory Oathkeeper documentation](https://www.ory.sh/docs/oathkeeper/pipeline/authn) and the [Ory Oathkeeper Decision Engine documentation](https://www.ory.sh/docs/oathkeeper#decision-engine).bland-finland-95044
03/07/2024, 9:26 PMchilly-king-10285
03/07/2024, 9:26 PMchilly-king-10285
03/07/2024, 9:27 PMAuthorization
header, while the cookie session authenticator would check for a valid session cookie. 3. Authorization: After successful authentication, Ory Oathkeeper proceeds to the authorization step. Access Rules can check permissions. For example, to secure an API that requires certain privileges, you would configure the authorizer to check if the user ID from the authentication step has the necessary permission or role. Ory Oathkeeper supports a variety of authorizers. 4. Mutation: The Access Rule can add session data to the HTTP request that it forwards to the upstream API. For example, the mutator could add X-User-ID: the-user-id
to the HTTP headers or generate a JWT with session information and set it as Authorization: Bearer the.jwt.token
. For more detailed information, you can refer to the [Ory Oathkeeper documentation](https://www.ory.sh/docs/oathkeeper/pipeline/authn) and the [Ory Oathkeeper Decision Engine documentation](https://www.ory.sh/docs/oathkeeper#decision-engine).bland-finland-95044
03/07/2024, 9:28 PMchilly-king-10285
03/07/2024, 9:28 PMchilly-king-10285
03/07/2024, 9:29 PMjson { "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. For more information, you can refer to the [Ory Oathkeeper documentation](https://www.ory.sh/docs/oathkeeper/pipeline/authn).bland-finland-95044
03/07/2024, 9:38 PMchilly-king-10285
03/07/2024, 9:38 PMchilly-king-10285
03/07/2024, 9:38 PMtoken
parameter in the --data
option. In curl
, you need to make sure that the JSON data is properly formatted. Here's an example of how you might format your curl
command: bash curl --location 'https://<MY ORY NETWORK PROJECT>/admin/oauth2/introspect' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <MY API KEY>' \ --data '{"token": "<TOKEN I'M CHECKING>"}'
Make sure to replace <MY ORY NETWORK PROJECT>
, <MY API KEY>
, and <TOKEN I'M CHECKING>
with your actual project URL, API key, and the token you're checking, respectively. If you're still encountering issues, I recommend checking the [Ory documentation](https://www.ory.sh/docs/reference/api) for more information on how to use the introspect endpoint.bland-finland-95044
03/07/2024, 10:20 PMchilly-king-10285
03/07/2024, 10:20 PMchilly-king-10285
03/07/2024, 10:20 PMjavascript import { Configuration, OAuth2Api } from "@ory/client" const ory = new OAuth2Api( new Configuration({ basePath: `https://${process.env.ORY_PROJECT_SLUG}.<http://projects.oryapis.com|projects.oryapis.com>`, accessToken: process.env.ORY_API_KEY, }), ) export async function createTrustRelation(accessToken: string) { const { data } = await ory.trustOAuth2JwtGrantIssuer({ trustOAuth2JwtGrantIssuer: { allow_any_subject: true, subject: "some-subject-id", expires_at: "2021-04-23T18:25:43.511Z", issuer: "<https://example.org>", jwk: { alg: "RS256", use: "sig", kty: "RSA", e: "AQAB", kid: "d8e91f55-67e0-4e56-a066-6a5f0c2efdf7", } } }) }
In this example, the issuer
and subject
are used to define the trust relationship, not the OAuth client ID. The allow_any_subject
field indicates whether the issuer is allowed to have any principal as the subject of the JWT.bland-finland-95044
03/07/2024, 10:34 PMchilly-king-10285
03/07/2024, 10:34 PMchilly-king-10285
03/07/2024, 10:34 PMread:calendar
scope, your application would check if the client has the read
permission on the calendar
object. Please note that the specific steps and code examples for mapping scopes to permissions are not provided in the extracts. For more detailed instructions and code examples, you should refer to the [Ory Keto documentation](https://github.com/ory/keto) and the [Ory OAuth2 and OpenID Connect documentation](https://www.ory.sh/docs/oauth2-oidc).bland-finland-95044
03/08/2024, 2:56 PMchilly-king-10285
03/08/2024, 2:56 PMchilly-king-10285
03/08/2024, 2:56 PMbash curl --location 'https://<MY ORY NETWORK PROJECT>/admin/oauth2/introspect' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <MY API KEY>' \ --data '{{"token": "<TOKEN I'M CHECKING>"}}'
Replace <MY ORY NETWORK PROJECT>
, <MY API KEY>
, and <TOKEN I'M CHECKING>
with your actual project URL, API key, and the token you're checking, respectively. The response will be a JSON object that includes an active
field. If active
is true
, then the token is valid. If active
is false
, then the token is not valid. Please note that the specific endpoint and method for token introspection may vary depending on your Ory configuration. For more detailed instructions, you should refer to the [Ory documentation](https://www.ory.sh/docs/oauth2-oidc/overview/oauth2-concepts#the-application-oauth2-client).