---
title: Native and single-page applications
description: For native applications and single-page applications, the default grant type to request access to protected resources is implicit.
component: pingone-api
page_id: pingone-api:foundations:authentication-concepts/authorization-and-authentication-by-application-type/native-and-single-page-applications
canonical_url: https://developer.pingidentity.com/pingone-api/foundations/authentication-concepts/authorization-and-authentication-by-application-type/native-and-single-page-applications.html
---

# Native and single-page applications

For native applications and single-page applications, the default grant type to request access to protected resources is `implicit`.

|   |                                                                   |
| - | ----------------------------------------------------------------- |
|   | Native applications also use the `authorization_code` grant type. |

For the `implicit` flow, the application is issued an access token without requiring an authorization code exchange. When the request is made to the `/{{envID}}/as/authorize` endpoint for an `implicit` grant type, the value of the `response_type` parameter is set to `token` or `id_token`.

If the request contains the `id_token` response type and the `openid` scope, then it is considered an authentication (OpenID Connect) request, and an ID token is issued. The ID token includes the ID of the user; this request can also include the `profile`, `email`, `address`, and `phone` OIDC scopes to add additional user claims to the ID token.

The following sample shows the `GET /{{envID}}/as/authorize` operation to return an `id_token`.

```bash
https://auth.pingone.com/{{envID}}/as/authorize?client_id={{appID}}&redirect_uri={{redirect_uri}}&response_type=id_token&scope=openid%20profile%20email&acr_values=Single_Factor&max_age=86400
```

The request can specify the `token` or `id_token` response types individually, or both. The following sample shows the `GET /{{envID}}/as/authorize` operation to return a `token` and an `id_token`:

```bash
curl --request GET \
  --url 'https://auth.pingone.com/{{envID}}/as/authorize?client_id={{appID}}&redirect_uri={{redirect_uri}}&response_type=token id_token&nonce=12345&scope=openid profile p1:read:user&acr_values=Single_Factor&max_age=86400'
```

In this request, the `p1:read:user` scope is included in the access token but not in the ID token.

The request URL contains the following parameter values:

* `response type`

  Specifies the response type for the authorization request. The `implicit` grant type requires a `response_type` parameter value of `token` or `id_token` (or both). This parameter is required.

* `client_id`

  Specifies the application's UUID, returned from a `GET /environments/{{envID}}/applications/{{appID}}` request. This parameter is required.

* `redirect_uri`

  Provides a URL that specifies the return entry point of the application. This parameter is required.

  |   |                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
  | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | To ensure proper redirect on some iOS and OSX browsers, the `redirect_uri` value must include a trailing slash. For example, a registered URI of `https://www.pingidentity.com/` redirects properly to `https://www.pingidentity.com/#access_token=eyJsdf`, but a registered URI of `https://www.pingidentity.com` redirects incorrectly to `https://www.pingidentity.com/en.html`, and the client application would not receive the access token. |

* `nonce`

  A string that is used to associate a client session with a token to mitigate replay attacks. The value is passed through unmodified from the authentication request to the token. This is a required property for authorization requests that return a `token`. It is not required for requests that return only an `id_token`.

* `scope`

  Specifies permissions that determine the resources that the application can access. This parameter is not required, but it is needed to specify accessible resources.

* `acr_values`

  An optional parameter that designates whether the authentication request includes specified sign-on policies. Sign-on policy names should be listed in order of preference, and they must be assigned to the application. For more information, refer to [Sign-on policies](../../../platform/sign-on-policies.html) in the *PingOne Platform APIs*.

* `max_age`

  An optional parameter that specifies the maximum amount of time allowed since the user last authenticated. If the `max_age` value is exceeded, the user must re-authenticate.

After all login action steps in the flow are completed successfully, the `GET /{{envID}}/as/resume` endpoint is called to continue processing the authorization request.

```bash
https://auth.pingone.com/{{envID}}/as/resume?flowId={{flowID}}
```

The authorization service generates the `token` or `id_token` for the application after restarting the authorization flow; it does not require a step to call the `/{{envID}}/as/token` endpoint.

|   |                                                                                                                                                                                    |
| - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | The authorization server can issue refresh tokens to native applications. However, when a native application uses the `implicit` grant type flow, a refresh token is not returned. |