Auth0 Home Blog Docs

Add API Metadata settings

api
rules
metadata

#1

We are currently using the Application Metadata feature in conjunction with a rule to limit SPA and web Application access to APIs. The idea is to restrict an Application from requesting a token for an API it shouldn’t have access to.

We would prefer it was the API that had the Metadata used to limit Application access, then use that data in a rule when an Application requests a token for that audience. Another option would be to add toggles for SPAs and web apps like those seen in the “Machine to Machine Applications” list in API settings.


#2

Inside the rules you should have access to the information you need to make these decisions.

context.request.query.audience will contain the API requested.

Then you can add application metadata to each client if you want to specify some flag to determine whether the requesting client has access. This application metadata can be set in the advanced settings of the application in the Auth0 Manage Dashboard. And then that data is accessible in context.clientMetadata in the rule.

Then you can reject authorization with return callback(new UnauthorizedError(“some text”));


#4

Yes, that’s what we are already doing. Maybe I didn’t describe that clearly.

We would prefer the API limits access, instead of the client. It seems backwards for a client to limits it’s access to an API.

That could either mean 1) add API Metadata settings that get added to rule context, or 2) add SPA and web apps to the “Machine to Machine Applications” list in the API settings so we can toggle access to cleints that way.


#5

Okay, I think I understand what you are asking now.

  1. That is an interesting feature request. There are likely to be improvements coming in the area of API context in rules. Right now there isn’t a strong API context during rules. The audience is only coming through as part of the original request.

  2. The machine-to-machine section is really only for client credentials flow. It does not impact user based flows. So, you can entitle a webapp (since webapps are confidential clients and can use client credentials flow to get an access token), but that won’t effect the ability to get an access token to your API using the /authorize flows (authorization code grant and implicit grant).

I’d be curious to understand your use case a little better. Generally API access is either strictly client based (using client credentials flow to authorize the “client/application” instead of a user) or user based. Client based would use machine-to-machine grants, but if it is user based, then it would generally be entitled based on the roles/permissions for the user instead of the client the user was using to access the data.


#6