ForgeRock OpenIG provides a simple standards-based approach to extend access to web applications and application programming interfaces (APIs).

A perfect complement to existing WAM systems or as a stand-alone gateway, OpenIG provides a flexible policy enforcement point to support your current environment while migrating toward a modern, standards-based platform.

Can optionally and would typically be coupled with OpenAM

OpenIG as an OAuth 2.0 Resource Server#

The OAuth 2.0 Authorization Framework describes a way of allowing a third-party application to access a user's resources without having the user's credentials. When resources are protected with OAuth 2.0, users can use their credentials with an OAuth 2.0-compliant identity provider, such as OpenAM, Facebook, Google and others to access the resources, rather than setting up an account with yet another third-party application.

When OpenIG acts therefore as an OAuth 2.0 Resource Server, the role is to validate Access Tokens. Typically the Resource Server validates an access token by submitting the token to a Token Introspection Endpoint. The Token Introspection Endpoint typically returns the Access Token and the OAuth Scopes associated with the token, potentially with other information. For example, OpenAM maps OAuth Scopes to user profile attribute values by default, and also allows custom scope handling plugins.

You maybe wondering Why Access Tokens?

OpenIG as an OAuth Client#

OAuth Client is the third-party application that needs access to a user's protected resources.

The client application therefore has the user (the OAuth 2.0 Resource Owner) delegate authorization by authenticating with an identity provider (the OAuth 2.0 Authorization Server) using an existing account, and then consenting to authorize access to protected resources (on an OAuth 2.0 resource server).

OpenIG can act as an OAuth Client when you configure an OAuth2ClientFilter. The filter handles the process of allowing the user to select a provider, and redirecting the user through the authentication and authorization steps of an OAuth 2.0 Authorization Code Grant, which results in the Authorization Server returning an Access Token to the filter. At the outcome of a successful authorization grant, the filter injects the Access Token data into a configurable target field of the exchange so that subsequent filters and handlers have access to the access token. Subsequent requests can use the access token without re-authentication.

If the protected application is an OAuth 2.0 Resource Server, then OpenIG can send the Access Token with the resource request.

More Information#

There might be more information for this subject on one of the following: