My app is an SPA React app which uses webauth to access an auth0 API, more or less what this tutorial describes. Most user interaction occurs in the webapp, but I would like to provide a Google App the ability to query against the API. This means it needs to be limited in which API endpoints it can access because I want to prevent any potential vulnerabilities.
Google Apps can support OAuth2 so I’ve created a separate client (native) to allow my Google Apps Add On to query my API. It more or less follows this template from their sample code and uses the jwt generated to make queries directly against my API. Now, while I want the Google Apps Add On to be able to query against my API, it should not have anything close to the permissions of my main React API client. What is the best way to restrict access to this separate client? Should it be a third-party client instead? Should I use a separate node middleware on top of checking the jwt to restrict endpoint access on client id? Was curious what best practice is here for adding additional OAuth clients that need to use a subset of API endpoints.
There are a couple of things to have in mind here, mostly because we are dealing with public clients. The client identifier is not treated as confidential information and by itself cannot be used as means of client authentication so in theory there will be occasions where a given client identifier does not give you any real information about who’s really behind the transaction (it could be your own application or a malicious one trying to pose as your application). In essence, if it involves a user there’s still some responsibility on that user to not do stupid things; for example, if he installs the wrong application and is tricked to give the keys to the kingdom either directly or indirectly you may not be able to do anything about it and as such restricting scopes based on client identifier is the least of your concerns.
In conclusion, although nothing stops you from restricting the set of scopes granted during an end-user based flow by looking solely at the client identifier this may not give you what you expect in some situations. Technically, the way you would currently implement that restriction would be through a custom rule that would constrain the scope on the issued access token using context.accessToken.scope, but if you go ahead with it have in mind the possible pitfalls.