In this scenario, a user attempts to access a protected resource through a third-party web server client. The client sends an authorization request to the resource server and receives an authorization code back via an HTTP redirect. The client trades the authorization code for an access token, and then uses the token in a API call to obtain data.
- User navigates to an OAuth client website (the requesting site) and requests access
to protected resources from another website.
The OAuth client can optionally include the parameter code_challenge (with or without code_challenge_method) to reduce the risk of code interception attack. For more information, see step 3 and Proof Key for Code Exchange by (PKCE) OAuth Public Clients (tools.ietf.org/html/rfc7636).
- The browser is redirected to the PingFederate OAuth AS with a request for
If the user is not already logged on, the OAuth AS challenges the user to authenticate. The OAuth AS authenticates the user and prompts for authorization. Once the user authorizes, the OAuth AS redirects the browser to the requesting site with an authorization code. If the user does not authenticate, an error is returned rather than the authorization code.
- The requesting site makes an HTTPS request to the OAuth AS to exchange the
authorization code for an access token.
If the OAuth client has provided the optional parameter code_challenge in step 1, it must submit the corresponding code_verifier in this request.
The OAuth AS validates the grant and user data associated with the code and then returns an access token.
- The requesting site uses the access token in an API call to request user data.
- The resource server (RS) asks PingFederate for verification that the token is valid and has not expired. PingFederate returns data about the user, the granted scope, and the client ID.
- Once verified, the RS returns the requested data to the requesting site.
- The requesting site displays data from the API call to the user.