---
title: Implicit grant type
description: For an implicit grant type, the response to the authorization request is an id_token, a token (access token), or both, depending on the value of the response_type parameter in the authorization request. The implicit workflow does not need to call the token endpoint. The response from the resume endpoint includes the token (or tokens) in the Location header.
component: pingone-api
page_id: pingone-api:foundations:authentication-concepts/authorization-flow-by-grant-type/implicit-grant-type
canonical_url: https://developer.pingidentity.com/pingone-api/foundations/authentication-concepts/authorization-flow-by-grant-type/implicit-grant-type.html
section_ids:
  implicit-authorize-request-using-get: Implicit authorize request using GET
  implicit-authorize-request-using-post: Implicit authorize request using POST
---

# Implicit grant type

For an implicit grant type, the response to the authorization request is an id\_token, a token (access token), or both, depending on the value of the `response_type` parameter in the authorization request. The implicit workflow does not need to call the token endpoint. The response from the resume endpoint includes the token (or tokens) in the `Location` header.

PingOne supports `GET` and `POST` HTTP methods for initiating the implicit authorize request.

## Implicit authorize request using GET

**Step 1:** Send an authorize request to the PingOne authorization server using `GET`.

```bash
curl --location --request GET '{{authPath}}/{{envID}}/as/authorize?response_type=token id_token&client_id={{appID}}&redirect_uri={{redirect_uri}}&scope=openid'
```

The request requires the following properties in the request URL:

* `response_type`: For an implicit grant the response type is `token`, `id_token`, or both.

* `client_id`: The application's ID.

* `redirect_uri`: The URL to redirect the browser after sign on.

* `scope`: The permissions that specify accessible resources.

The response returns a `Location` HTTP header that specifies the URL for the sign-on screen and the flow ID for the sign-on workflow. For information about additional optional query parameters that can be set on the request, refer to [Authorize (implicit)](../../../auth/openid-connect-oauth-2/authorize-implicit.html#get-authorize-implicit-get) in *Platform Auth APIs*.

**Step 2:** After the sign-on flow completes, call the resume endpoint. \\

```bash
curl --location --request GET '{{authPath}}/{{envID}}/as/resume?flowId={{flowID}}' \
--header 'Cookie: {{sessionToken}}'
```

The request requires the following properties in the request URL:

* `flowID`: The ID for the authentication flow.

The `Location` HTTP header returned by the resume endpoint contains the token, ID token, or both. Note that the PingOne API uses session token cookies to establish the user's authentication session and maintain the session throughout the workflow, allowing the flow to redirect back to the authorization server to get the token.

## Implicit authorize request using POST

The `POST` request accepts all the same parameters as the `GET` request. For the ``POST request, parameters and their values are Form Serialized by adding the parameter names and values to the entity body of the HTTP request and specifying the `Content-Type: application/x-www-form-urlencoded`` request header.

**Step 1:** Send an authorize request to the PingOne authorization server using `POST`.

```bash
curl --location --request POST '{{authPath}}/{{envID}}/as/authorize' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'response_type=token id_token' \
--data-urlencode 'client_id={{appID}}' \
--data-urlencode 'redirect_uri={{redirect_uri}}' \
--data-urlencode 'scope=openid'
```

The request requires the following properties in the request URL:

* `response_type`: For an implicit grant the response type is `token`, `id_token`, or both.

* `client_id`: The application's ID.

* `redirect_uri`: The URL to redirect the browser after sign on.

* `scope`: The permissions that specify accessible resources.

The response returns a `Location` HTTP header that specifies the URL for the sign-on screen and the flow ID for the sign-on workflow. For information about additional optional query parameters that can be set on the request, refer to [Authorize (implicit)](../../../auth/openid-connect-oauth-2/authorize-implicit-1.html#post-authorize-implicit-post) in *Platform Auth APIs*.

**Step 2:** After the sign-on flow completes, call the resume endpoint.

```bash
curl --location --request GET '{{authPath}}/{{envID}}/as/resume?flowId={{flowID}}' \
--header 'Cookie: {{sessionToken}}'
```