-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Granted Endpoint Proposal: Performant access decisions for resource providers using REST #48
Comments
This allows a user or system admin to reflect on a users account, and see all the things they are authorised to do ? Like auditing you could say ? |
Yes, I think that is a good summary! Whops, clicked close and comment |
Ok nice feature. As a system grows it helps allot On Mon, 8 Feb 2016, 13:21 Aeneas notifications@github.com wrote:
|
Cool! Thank's for looking over it :) Did you check out how policies work? |
wow you have been busy. i gave it a quick read. yes acls basically suck once the code and api expands. how is the ability to audit coming along as per this main issue. |
Yeah still some cleaning up to do and test cases to write. Docs will follow alongside :) |
Right now, there is no endpoint for resource providers. They rely on the guard and introspect endpoint. I propose to merge the guard and introspect in a new and powerful endpoint called Granted (available at
/oauth2/granted
). This endpoint requires:Header
Authorize: basic
with a client id and secret. The client must exist and be explicitly allowed to access the lookup endpoint.POST JSON Body
token: {token}
: The access token to be inspectedresource: {resource-name}
: The resource that is being accessedpermission: {permission}
: The permission that is being requiredcontext
: A object for decisions based on conditions.resourceOwner: {owner-id}
: The resource's ownerrequestIP: {request-ip-address}
: The IP address which issued the requestrequestedAt: {ISO-8601-date}
: The time the request was issuedrequestUserAgent: {request-user-agent}
: The user agent that issued the requestNon-normative example:
Response JSON
granted: {true|false}
: If access was granted to the tokenerror: {message}
: Error explains why the grant request was denied. Only set if access was denied.Errors
This prevents third parties from using this endpoint. Third parties should use the introspect endpoint instead, because it checks if token audience and client id match, which is not required for resource providers!
The text was updated successfully, but these errors were encountered: