After installing an OA4MP server, or as part of testing one in service, you may want to have a way to monitor the interaction from the command line. There are two ways to do this, either using the custom command line client or using curl. This document is how to test using curl. This is not quite straightforward and does require some work, but in many cases is well worth the effort. This document describes how to do a complete exchange with a properly configured OA4MP server


You should make sure you have a few things at the ready.

  • A valid, registered client and its ID
  • The client should not be running, or the client does not exist, meaning that you register a client and use a valid but bogus callback uri. If the callback uri is valid, the server will try to contact it, as per the spec.
  • A url encoder or decoder. I like this one.
  • A valid certification request. You can create on using openssl, or you can invoke
  • Access to the server from the command line. Depending upon your setup this may require you to be logged in to the server and send everything to localhost.

The steps

Each of the steps is outlined below along with an example curl call. In each call you will need to supply your own client_id, client_secret and redirect_uri. Other values such as the nonce and state may be left as is.

Step 1: The authorization page

In this case, you will create a custom url that you will paste into your browser. Line breaks are for readability.


Step 2: Get authorized.

At this point you should see the authorization page pop up in your browser. Log in. The normal control flow is to call back to the redirect URL you provided in the previous step. Since no client should be running there, you will get an error.

Step 3: Grab the authorization grant (aka code) from the browser location bar.

The location bar will have an address like this in it


Note that the state passed in initially is returned. You can ignore this. The important thing is the code. This must be swapped out for a access token.

Step 4:Getting an access token.

This requires a little more work since you have to do a POST (as per the spec) using cURL. In this example, I am using the -k flag to avoid checking the SSL cert for the server. This may or may not be required for your setup and the -d parameter that gloms together the request, allowing it to be entered on multiple lines:

    curl -k --location -d code=https%3A%2F%2Fsurge.ncsa.illinois.edu%2Foauth2%2FauthzGrant%2F6d08e01649cb7d766b0c6288333377b1%2F1453837119100 \
    -d client_id=myproxy%3Aoa4mp%2C2012%3A%2Fclient_id%2F2a3aab4b67ab2354563 \
    -d client_secret=KYuXckx3yilsiwl6Z3934587KSUIF983489_3498drfgn3 \
    -d redirect_uri=https%3A%2F%2Fashigaru.ncsa.uiuc.edu%3A9443%2Fclient%2Fready \
    -d grant_type=authorization_code \

Note that the actual endpoint goes at the end of this request. You should get a response like this:


Again, you just need the access_token.

Step 5: Use your cert request.

It is assumed you generated a cert request before you started. In that case, you need to URLencode the cert request you created and send it along in the request (which is just a GET).

    curl -k --location

The response is just the certificate.