Skip to content
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

Enforce OAuth Access Token Scope requirements #22

Closed
nynymike opened this issue Oct 13, 2021 · 3 comments
Closed

Enforce OAuth Access Token Scope requirements #22

nynymike opened this issue Oct 13, 2021 · 3 comments

Comments

@nynymike
Copy link

Ideally, when I design an endpoint, I should be able to say how each method is authorized. In OAuth, we use scopes to determine the extent of access granted for an access_token ("AT"). The AT may be a value token: a JWT requiring signature validation (and auto-fetching of the current keys). The AT may also be a reference token: a guess-resistent identifier requiring OAuth token introspection. In either case, the AT should contain the scope claim, which is a space-delimited list of scopes (normally in URI format).

In the example below, the swagger doc is saying that to do a GET on the persistence endpoint, you need to present a token with either the properties.read OR properties.write scope

/jans-config-api/api/v1/jans-auth-server/config/persistence:
    get:
      summary: Returns persistence type configured for Jans authorization server.
      description: Returns persistence type configured for Jans authorization server.
      operationId: get-properties-persistence
      security:
        - oauth2: [properties.read, properties.write]

For extra credit, you can consider how the scopes are combined. Can you use AND instead of OR for a given endpoint? For more complex booleans, you could support JSONLogic syntax.

@afr1ka
Copy link
Collaborator

afr1ka commented Oct 19, 2021

Hello nynymike,

Unfortunately, right now we don't support in-depth security requirements analysis (token validation, scope checks and etc.). API-Firewal just checks that you have an "Authorization" header without validation of its content. But we have some ideas regarding integration with OAuth services in the API-Firewall roadmap.
Could you please provide any details regarding OAuth provider you are using? It will help us to adjust our tasks.

Thanks.

@nynymike
Copy link
Author

nynymike commented Nov 9, 2021

I am CEO of Gluu, so of course we use Gluu Server 4.x. The upstream project is Janssen Auth-Server at the Linux Foundation.

@d0znpp
Copy link
Contributor

d0znpp commented Dec 1, 2021

this feature will be included in the next release

@d0znpp d0znpp closed this as completed Dec 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants