!!! Overview
[ForgeRock] [{$pagename}] 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]

!! [{$pagename}] 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 [{$pagename}] 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]?

!!  [{$pagename}] 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).

[{$pagename}] 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 [{$pagename}] can send the [Access Token] with the resource request.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]