---
title: Authorization
description: The authorize endpoints support the following actions:
component: pingone-api
page_id: pingone-api:auth:openid-connect-oauth-2/authorize-intro
canonical_url: https://developer.pingidentity.com/pingone-api/auth/openid-connect-oauth-2/authorize-intro.html
---

# Authorization

The authorize endpoints support the following actions:

* The authorize endpoint `/{{envID}}/as/authorize` is used to interact with the end user and obtain an authorization grant. Note that PingOne supports both `GET` and `POST` operations for authorize requests. The supported parameters for an authorize request vary depending on the value of the `response_type` parameter (`code`, `token`, `id_token` or 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_mode` property value is set to `pi.flow`. This setting allows the app to authenticate using the PingOne flows API without needing to handle HTTP redirections. The `pi.flow` value 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_token` grant type, when the authorize request includes `offline_access` in the `scope` parameter, and the request specifies the `authorization_code` or `device_code` grant type, a refresh token is always included in the token response. Otherwise, if the `offline_access` scope is omitted from the `scope` parameter of the authorize request, a refresh token is not included, even if the `refresh_token` grant type is defined in the application configuration. Refer to [Application Resource Grants](../../platform/applications/application-resource-grants.html) to add the `offline_access` scope to the application's resource grant.

  If the application does not have a resource grant that includes `offline_access` in the `scope` parameter, a refresh token is always included in the token response for grant types that allow it.

  |   |                                                                                                                                                                                                                                                                                                                                                                   |
  | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | If the client includes `prompt=consent` in a request with an `authorization_code` grant type, PingOne doesn't prompt for application consent. This limitation doesn't apply to requests with a `device_code` grant type, because the PingOne authentication policy service always prompts for application consent when requests use the `device_code` grant type. |

> **Collapse: Related topics**
>
> * [Authorization and authentication by application type](../../foundations/authentication-concepts/authorization-and-authentication-by-application-type.html)
>
> * [Authorization flow by grant type](../../foundations/authentication-concepts/authorization-flow-by-grant-type.html)
>
> * [Access services through scopes and roles](../../foundations/pingone-roles-scopes-and-permissions/access-services-through-scopes-and-roles.html)