On the scopes page for an API (and in the help section on scopes), there is a warning-
By default, any user of any application can ask for any scope defined here. You can implement access policies to limit this behavior via Rules.
My question is - what is meant by “By default, any user of any application can ask for any scope defined here”?
In my scenario, we are using “Machine to Machine” authentication. We have specified an API “Test API” with multiple scopes, “test:scope1” and “test:scope2”. When creating an application, we are required to specify which API and which scopes are enabled.
In my testing, tokens are only issued for applications which are enabled for that API, and scopes are limited to the enabled scopes.
Does this mean we are “non-default”, and therefore the warning is not applicable?
When you define an API there are two types of flows where an access token for that API may be issued:
- an end-user based flow.
- a client credentials based flow also referred to as machine to machine authentication.
For the second flow, each machine to machine application needs to be pre-authorized by a dashboard administrator for each API and as part of this configuration you can restrict the scopes that the machine to machine application can be granted.
The warning, however, applies to the first flow where any client application (a SPA, server-side or native application) that allows end-users to authenticate is allowed to also request an access token for a configured API. In this flow, there are no restrictions applied by default to the scopes that the end-user/client application can request.
As additional information, we are working on making additional built-in features available that would allow for restrictions to be applied without the need for custom rules even for the first flow; although, your would still need to opt-in to those so by default the content in the warning would still apply. Reference documentation is already available at (https://auth0.com/docs/authorization/guides/how-to).
In conclusion, the warning is applicable to your tenant domain unless you only have machine to machine applications within the tenant domain the API is defined.
Thanks for your reply!
I’m still a bit unclear - could you give an example of a possible attack scenario if this was misconfigured?
I’m asking as we believe we are covered, but with an example attack we could verify that we are covered.
(If more information is needed, I’m happy to open a support call and talk through our current setup.)
In conclusion, the warning is applicable to your tenant domain unless you only have machine to machine applications within the tenant domain the API is defined.
If an API is only enabled for M2M applications, is this warning not applicable? Even if there are other non-M2M applications in the tenant?
What you need to consider is that if an API exists in the tenant domain and an application is also configured in that domain then the API is enabled by default for end-user flows through that application.
In relation to possible issues, lets say your service exposes an administration API with scopes read:service_data and delete:service_data and that you intend for this API to only be called by a specific back-end service named SVC_X.
If you represent the back-end service SVC_X as a M2M application you can then configure a grant and allow that service to obtain tokens for the API. You can configure additional M2M applications and those by default will NOT be able to get access tokens for the API.
However, if you have SPA_Y in your tenant with public signup, by default any end-user of SPA_Y will be able to adjust the authentication flow to include an audience parameter for the API and in this way obtain a token for scope delete:service_data.
The above could be an issue and that is what the warning is about; by default end-user flows will be able to request any scope defined for the configured API’s.
1 Like
Thanks very much for the clear reply - in fact, it’s highlighted that we were allowing end-users to access any API (scopes or no scopes), which we are looking to now stop.
In terms of resolving this issue - I can see two options-
a) adding a custom rule to validate audience and/or scopes
b) setting an “Allowed API” in the Advanced Settings of an Application
Give this Auth0 article “Restrict Application or User Requests for API Scopes”, it seems that rules are the approved way to restrict APIs from end-users?
Also, some feedback to Auth0- I understand I may be my lack of familiarity with OIDC protocol, but given that Auth0 has “enabled/disabled” switches on the APIs, I was surprised that end-users had access to “denied” APIs. If it weren’t for the warning when adding scopes, we may have missed this issue. I’m not sure how to make this issue more visible to developers, but I feel it is important.
Yes, the article you linked to would be the preferred way to deal with a scenario where you want to prevent end-user access to a specific API and in this way have that API available only for client credentials flows. In particular, the rule sample at this section (https://auth0.com/docs/api-auth/restrict-requests-for-scopes#example-deny-access-to-anyone-calling-the-api) would be relevant.
In relation to feedback, the preferred way for providing feedback would be through Auth0: Secure access for everyone. But not just anyone. because in that way the feedback will be automatically linked to you and you will also be able to express it in your own words and with the exact context you desire. If you can spare the time that would be my recommendation, if not just leave a quick message here and I’ll submit your last paragraph above myself.