Authorization
The authorize endpoints support the following actions:
-
The authorize endpoint
/{{envID}}/as/authorizeis used to interact with the end user and obtain an authorization grant. Note that PingOne supports bothGETandPOSToperations for authorize requests. The supported parameters for an authorize request vary depending on the value of theresponse_typeparameter (code,token,id_tokenor combinations of these three options). -
For non-redirect flows, such as with native mobile apps in which the app renders the end user interface,
response_modeproperty value is set topi.flow. This setting allows the app to authenticate using the PingOne flows API without needing to handle HTTP redirections. Thepi.flowvalue is also used with transaction approval use cases in which strong authentication is required for elevated security for a high-value transaction, or high-risk resource or service. -
For offline access, on applications having a
refresh_tokengrant type, when the authorize request includesoffline_accessin thescopeparameter, and the request specifies theauthorization_codeordevice_codegrant type, a refresh token is always included in the token response. Otherwise, if theoffline_accessscope is omitted from thescopeparameter of the authorize request, a refresh token is not included, even if therefresh_tokengrant type is defined in the application configuration. Refer to Application Resource Grants to add theoffline_accessscope to the application’s resource grant.If the application does not have a resource grant that includes
offline_accessin thescopeparameter, a refresh token is always included in the token response for grant types that allow it.If the client includes
prompt=consentin a request with anauthorization_codegrant type, PingOne doesn’t prompt for application consent. This limitation doesn’t apply to requests with adevice_codegrant type, because the PingOne authentication policy service always prompts for application consent when requests use thedevice_codegrant type.