And one more thing, is there any chance of allowing users to generate API Key with specific scopes or something like that? API Key will allow access to their account (and other resources) but only within allowed scopes?

Hello Vasilije, Ory generally does not have a service for API keys - what were you looking at specifically?

Hi Vincent, I'm looking for a way to allow my customers to generate API keys for their accounts. Similar to an OAuth2 client, but without the full OAuth2 authorization flow. What I need: • Customers should be able to generate API keys from their account settings. • Each API key should be linked to their identity and allow access to our API. • The API key should be permanent or expire after a configurable period. • API keys should have scopes so that customers can restrict access to certain features. • These keys are only for accessing our API, not for managing Ory account settings. • When an API request is made using a key, we should be able to identify the user and check granted scopes. Would this be possible to implement with Ory, or would I need to handle API key generation separately?

It is possible to implement through OAuth2 probably - but its not really intended for that. We do have plans for a separate service that would fit this use case exactly, but it is planned for later this year, so not available right now. I would recommend to check if you can find a different solution for the API keys specifically - you can still use Ory to manage users/identities/sessions and use the Ory OAuth2 offering to manage scopes - but scopes aren't permissions! So I think OAuth2 is not really what you are looking for. Quoting from our blog: > OAuth2 tokens have a scope. The scope is usually something like

read:user

or

profile:write

. The OAuth2 scope doesn't say what a user can and cannot do. > An access token represents that the client application has been authorized by the user. It states what a user said (consent!) a third party application can do in their name. Let's take a quick look at the OAuth2 flow: > 1. The client application asks the user if they can access a protected resource on their behalf (by redirecting the user to the authorization server’s authorization endpoint, specifying exactly what they would like to access (scopes)). > 2. The user identifies themselves to the authorization server (but remember, OAuth isn't authentication; you’ll need OpenID Connect to help you with that). > 3. The user authorizes the client application to access the protected resource on their behalf (using the OAuth consent process). > 4. The client application is issued an access token. > For example: > 1. Alice allows myphotoapp to access her Facebook photos. > 2. Bob allows mytodolist to access his Google Calendar. > Let's make a counterexample: > If Alice would allow myphotoapp to act as an administrator of the system and delete the production database, it would not matter unless Alice is actually a system administrator. Similarly, Alice can not allow myphotoapp access to Bob's pictures, because she isn't Bob. > I have lost count of the number of times developers have gotten this wrong. And again, it's not because people aren't skilled. it's because complex protocols have steep learning curves and ain't nobody got time to learn everything. As said before complexity kills security. See also this blogpost: https://www.scottbrady91.com/oauth/oauth-is-not-user-authorization

Sorry VIncent, I probably expressed myself incorrectly in my previous message and that got us into misunderstanding. I understand how scopes should be used, and I already apply them that way in my applications. They are not used as permissions but rather as you described. Even if a token includes certain scopes, that doesn’t guarantee the action can be performed—it simply grants the possibility, provided the user has the necessary permissions. If the user lacks permission, the action will fail due to insufficient privileges. Conversely, if the user has the required permission but the token lacks the appropriate scope, the action will fail due to a missing scope. So you recommend me to do it similar to what Microsoft does with their API Keys on Azure, customers needs to create OAuth2 application and then authenticate themself for their requested scopes in order to get token that can be used as API Key? API Keys will be more user friendly, they can generate it easily and use it. But if not yet possible I can stick with what I have. I can also implement that in my API independently from Ory but I think it will be better to be done through Ory or similar rather then me controlling the auth.