# USE OF POSTMAN WITH OPENID CONNECT PKCE AND API

- Link: https://www.agilicus.com/use-of-postman-with-openid-connect-pkce-and-api/
- Published: 2020-10-02T02:51:44+00:00
- Author: Don Bowman

OAuth 2.0 (on which OpenID Connect is based) supports many `flows`. These are essentially
different ways of using it, you will hear words like `implicit flow`, `PKCE flow`,
etc.

As a web application, the gold standard is (usually) The Proof Key for Code Exchange(
PKCE), specified in [RFC 7636](https://tools.ietf.org/html/rfc7636). It fixes the
problem of needing a `client secret` (which cannot be safely shared into a web client).

Many API’s, Agilicus’ included, use [OpenAPI](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md)
to specify how they function. Authentication of these is usually left out of scope,
but, provided as a bearer token. This means that if you write a web application,
you want to directly use the RESTful API’s, and you do so by first authenticating
via OpenID Connect PKCE flow and remembering the access token.

As a developer, you may use a tool like _[Postman](https://www.postman.com/)_, which
allows you to interactively experiment with the API. Recently (as of [v7.23.0](https://www.postman.com/downloads/canary),
aka Canary) they have added this support. Let’s try.

First, we install the Postman (v7.23.0 or later).

Second, we get the OpenAPI Specification. Agilicus has this linked on the top right
of our [website](https://www.agilicus.com/) as [API](https://www.agilicus.com/api/).
We select `Get New Access Token`.

![Postman configuration for OpenID Connect PKCE flow to access an API. Shows the
Postman interface with settings for authorization URL, access token URL, client 
ID, code challenge method (S256), code verifier, and callback URL. Highlights the
steps involved in configuring Postman for secure API authentication using OpenID
Connect and PKCE.](https://www.agilicus.com/www/2020/04/image.png)

Now we we have a dialog popup. Postman has not implemented the `discovery` mechanism,
so let’s take a look in another window how to find the answers. We’ll need `callback`,`
authorization_endpoint`, `token_endpoint`, `client ID`, `scopes`. Your auth endpoint
in this curl will vary as your top-level domain. The `callback` in Postman terminology
is the redirect URI, use `urn:ietf:wg:oauth:2.0:oob`.

    ```wp-block-code
    $ curl https://auth.cloud.egov.city/.well-known/openid-configuration
    {
      "issuer": "https://auth.cloud.egov.city/",
      "callback": "https://auth.ca-1.agilicus.ca/egov/",
      "authorization_endpoint": "https://auth.cloud.egov.city/auth",
      "token_endpoint": "https://auth.cloud.egov.city/token",
      "jwks_uri": "https://auth.cloud.egov.city/keys",
      "userinfo_endpoint": "https://auth.cloud.egov.city/userinfo",
      "revocation_endpoint": "https://auth.cloud.egov.city/token/revoke",
      "response_types_supported": [
        "code",
        "id_token",
        "token"
      ],
      "subject_types_supported": [
        "public"
      ],
      "id_token_signing_alg_values_supported": [
        "RS256"
      ],
      "scopes_supported": [
        "openid",
        "email",
        "groups",
        "profile",
        "offline_access"
      ],
      "token_endpoint_auth_methods_supported": [
        "client_secret_basic"
      ],
      "claims_supported": [
        "aud",
        "email",
        "email_verified",
        "exp",
        "iat",
        "iss",
        "locale",
        "name",
        "sub"
      ]
    }
    ```