Hi, we are on Ory production plan and want to do the following flow: • Allow users to login using Oauth2 client with limited scopes (e.g. open_id and offline_access only) • After login, we have some logic in our backend to identify what scopes should actually be given to this user • We want to be able to create a new token for this user with the new scopes Is this a valid flow? How can we achieve it?

I am not sure what exactly your logic does, but the two ways to customize claims are a) custom consent UI https://www.ory.sh/docs/oauth2-oidc/custom-login-consent/flow b) webhooks https://www.ory.sh/docs/hydra/guides/claims-at-refresh There is not really a way to update tokens later, or get new ones with other claims.

@steep-lamp-91158 thank you for replying. For more context, what we want to achieve is to be able to supply different scopes based on the user that is logging in. E.g. If User A logs in, User A should be given a JWT token with certain scopes like ["product:read", "users:read"]. Then for User B, his/her scope could be different like ["product:write"] We are also using Keto for RBAC, but is there a way for Keto and Hydra to integrate together to handle such a flow? cc @gorgeous-jackal-95562

What we are essentially looking for a token exchange mechanism which is standard thing in OAuth 2.0 Token Exchange (RFC 8693). Does Ory allow to get an elevated token? If so, we are looking for the specific REST API. There are several use-cases for these beyond what Alicia had shared here. I could achieve this by

hydra-cli

last time using OAuth client_id and credentials.

hydra perform client-credentials --client-id "$code_client_id" --client-secret "$code_client_secret" --scope "openid offline_access"

vs

hydra perform client-credentials --client-id "$code_client_id" --client-secret "$code_client_secret" --scope "openid offline_access new_scope_1 new_scope_2"

However, we wish to achieve the same for user token without using client-credentials and via the token exchange mechanism.

What you really want to do is what I already wrote before: 1. A custom consent UI can set arbitrary claims (server-side), including e.g. results from permission checks with Keto. 2. A webhook can also set arbitrary claims on token issuance and refresh, including e.g. results from permission checks with Keto. As the permissions are probably subject to change, you'd want very short-lived tokens and use the webhook to constantly re-check permissions on token refresh.

A custom consent UI can set arbitrary claims (server-side), including e.g. results from permission checks with Keto.

Thanks for your reply, Patrik. We’re considering how best to manage claims and permissions within our product while using Ory’s tools. Specifically, we want to avoid showing our users a consent form each time there’s a change to the claims, as this could create a poor user experience.

A webhook can also set arbitrary claims on token issuance and refresh, including e.g. results from permission checks with Keto.

This seems like a more suitable approach for our use case. Before moving forward, I want to make sure I understand this correctly. We’ve made two key decisions that align with our product goals: • We will use Ory’s login UI instead of creating a custom UI to streamline the login experience. • We do not plan to show additional consent forms to users when arbitrary scopes are added by us. With that in mind, here’s how I understand the process: 1. The user logs in, and we receive a user token. 2. We use the JWT token to call our backend APIs. 3. We perform permission checks with Ory Keto and add the necessary arbitrary scopes. 4. We set the arbitrary claims and issue a new token via a webhook. 5. The new token includes all the updated claims. Is this understanding correct?

Kinda, I suggest you go through the docs I send.

Before the token is issued to the client, Ory will call your HTTPS endpoint with information about the OAuth client requesting the token.

Your endpoint's response to the webhook will be used to customize the token that Ory issues to the OAuth client, and optionally overwrite the session data stored for the resource owner.

@fancy-toddler-44820 - let's try this. Thanks @steep-lamp-91158

@steep-lamp-91158 Is there a guaranteed timeframe for when the webhook will be triggered? What happens if the webhook notification fails to deliver, and does your system attempt to retry?

As the webhook response is needed for the token to be issued, it is called synchronously with retries. If it fails, then the token cannot be issued, so the whole OAuth2 flow fails.