search

auth0 / auth0-authorization-extension

Auth0 Extension that adds authorization features to your account
https://auth0.com/docs/extensions/authorization-extension/v2
Other
81 stars 55 forks source link

Feature Request: support APIs, not just Applications #157

Open AndreaCuneo opened 7 years ago

AndreaCuneo commented 7 years ago

Currently roles and permissions can only be linked to Clients (SPA, Native App, WebApp), not to APIs.

In my scenario I've got a matrix of WebApp and APIs. Many WebApps (or non-interactive clients) can connect to the APIs each with difference scopes. While handling the user authorized scope is fine (openid), I still need to merge it with user authorization on the API service. For example, in a calendar app, backed in an API, a user may have or not been given the permission to view calendars of other users of the same department.

In a WebApp I would have a role ("Calendar Department Admin") which would be granted the permission "read:cal:department". That would be fine. This doesn't really map to a scope a user can grant to another application, or at least a user can't grant a scope for a permission he doesn't have.

Is there a viable workaround?

markgould commented 7 years ago

Yeah, we need some more clarification on how this is supposed to work now that APIs are separate entities. If I have a native app with permissions defined, do we need to write rules that map permissions to scopes on an api?

valeriomazzeo commented 7 years ago

I think the main point is that from an authorisation point of view, permissions applies to APIs rather than client, with the distinction that we could have more than one client connecting to the same API.

Imagine the following scenario:

API (Application): Timesheets Clients: iOS, Android

I want to setup the permission for my API, not for my clients.

axos88 commented 7 years ago

We're facing the same situation.

The returned roles and permissions should be either the concat of the aud and azp, or the aud only.

duhseekoh commented 6 years ago

Anyone from auth0 ever look at these?

valeriomazzeo commented 6 years ago

@markgould is this extension dead?

markgould commented 6 years ago

@valeriomazzeo I don't know, I don't work for auth0

axos88 commented 6 years ago

@AndreaCuneo @valeriomazzeo @markgould This can be worked around by defining a client as an SPA or RWA and assigning permissions, rules to that. The API's identifier should be set to the client ID of the SPA or RWA created, and the rule can be set up to request the audience of the request rather than the client ID, if it is set... It's a pretty gruesome hack, but you get back the correct data.

valeriomazzeo commented 6 years ago

Is this making progress of any sort?