OAuth Scopes\Claims Restriction



Access Manager allows you to use OAuth2.0 protocol for authentication and authorization.

When using OAuth2.0, each application can get an access token by choosing one of the supported methods (Authorization Code, Implicit, Resource Owner Credentials, Client Credentials, SAML 2.0 Assertion).

When configuring a Resource Server, you can define as many scopes as you want:

Resource Server Scopes

Each access token is assigned with a scope that is being requested by the application on the authorization and token endpoints.

In addition to the authentication and authorization, the Access Manager has a UserInfo Endpoint that is used for getting Resource Owner's claims. A client can send a request to UserInfo endpoint with a valid access token and get the claims that are authorized by Resource Owner to share.

Each scope can be assigned with claims (user attributes or virtual attributes), which is returned on the UserInfo response, if and only if the access token contains that specific scope.

The Problem

Access Manager does not restricts OAuth2.0 applications from requesting and receiving scopes.

All scopes are published on the "scopes_supported" at the authorization server's OpenID Metadata Endpoint.

That means that if we published a scope names "email", that contains the user's email address, all applications will be able to request this scope, and we will not be able to restrict that.

The way the this restriction may be achieved on Access Manager is by using "User Consent" flow, where the user is permitting\denying the application from getting a specific attribute, but this is not happening when we choose to not require the user permissions (consent) for this specific flow:

User consent disabled for scope

We want to be able to restrict application access to specific claims - the same as we have on SAML and WS-Federation.

The Solution

We wrote a simple Java Servlet filter that can be integrated with the NIDP web application and restrict applications access to specific scopes.

Using this filter, you can define scopes that are public allowed for everyone, and scopes that are specific allowed to specific applications.

How to use the filter

    • On each identity server, create a configuration file (default location is /etc/edp/config/oauth_filter.xml). An example for this file can be found here:


    • Define all public allowed scopes under the  tag, using a tag. For example:


    • For each application, define a  tag under the  tag. clientScopes tag describes the allowed scopes for each application. For example:


    • The above example allows email scope for the first application, and both email and phone to the other one.


    • Download latest EDPNAMFilters jar file from my github


    • Copy the file to the Identity Server, and put it on /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib


    • edit /opt/novell/nam/idp/webapps/nidp/WEB-INF/web.xml file and add the filter and filter mapping:


    • restart Identity Server: /etc/init.d/novell-idp restart

Now, every client that tries to request a scope that he is not allowed for, will get a HTTP 401 error from the Authorization Endpoint (/oauth/nam/authz)

How to modify the filter configuration

    • Edit you xml configuration file (default location is /etc/edp/config/oauth_filter.xml) and save.


    • Configuration is automatically reloaded by the filter upon file save  - no restart needed.


Source Code

The source code of the filter can be found on my GitHub account:





How To-Best Practice
Comment List