This document provides a developer overview of the OAuth 2.0 protocol. It provides an overview of the processes an application developer and an API developer need to consider to implement the OAuth 2.0 protocol.
Explanations and code examples are provided for "quick win" integration efforts. As such they are incomplete and meant to complement existing documentation and specifications.
This document assumes familiarity with OAuth 2.0 protocol and PingFederate. For more information about OAuth 2.0, refer to:
- PingFederate Administrator's Manual
- OAuth 2.0 RFC 6749
The samples described in this document use the OAuth2 Playground sample application available for download from the products page on pingidentity.com.
The OAuth 2.0 protocol uses a number of actors to achieve the main tasks of getting an access token and using an access token. In addition, optional steps of refreshing this access token and validating the access token are also described.
The main actors involved are:
| User or Resource Owner | The actual end user, responsible for authentication and to provide consent to share their resources with the requesting client. |
| User Agent | The user's browser. Used for redirect-based flows where the user must authenticate and optionally provide consent to share their resources. |
| Client | The client application that is requesting an access token on behalf of the end user. |
| Authorization Server (AS) | The PingFederate server that authenticates the user and/or client, issues access tokens and tracks the access tokens throughout their lifetime. |
| Resource Server (RS) | The target application or API that provides the requested resources. This actor will validate an access token to provide authorization for the action. |