In OpenAM, the OAuth 2.0 Authorization Server and OAuth 2.0 Client authentication module are distinct implementations.
OpenAM's AS implementation makes it possible to use OAuth 2.0 Client applications with OpenAM independently of OpenAM's native mechanisms for protecting web resources and applications. The authentication module makes it possible for OpenAM to act as an OAuth 2.0 Client on behalf of applications that might not support OAuth 2.0 at all, enabling such applications to work with other OAuth 2.0 Authorization Servers and OpenID Providers while benefitting from protection through OpenAM's native mechanisms.
This should be clarified in the OpenAM documentation. The documentation on Configuring OpenAM as Authorization Server & Client and Hints For the OAuth 2.0 Authentication Module can leave readers wondering how the two implementations work together and overlap.
It should be made clear in the documentation that successful authentication with the OAuth 2.0 module can lead to an OpenAM session, with the OAuth 2.0 access token being consumed by OpenAM. (Thus OAuth 2.0 is simply a way to authenticate and retrieve information from a 3rd party identity provider, and OpenAM subsequently handles authorization to access resources. In other words, the access token is used only to retrieve information, not to access resources on the resource servers, which are assumed to be protected by OpenAM policy agents.)
It should also be made clear that OpenAM session timeout and OAuth 2.0 access token timeout are intentionally independent and separate in the configuration. OpenAM session timeouts are set to govern the duration of a single sign-on session across resources that OpenAM protects. OAuth 2.0 access token and refresh token expiration should be set to fit the use case for the resources protected by OAuth 2.0.