API Authentication Method in ELM – OIDC

In my last post I took you thru the OAuth 1.0a API flow.  While there are three APIs defined in the RootServices document which enable you to execute the flow, it is still a lot of work to ultimately get your OAuth 1.0a Token for usage.  This token is only valid for a short period of time, meaning your code need to constantly check for its availability, and once it fails, you need to process the same steps again to gain a new token.

Now let’s look at using OIDC authentication. 

Initial Setup

First, our ELM instance must be configured to utilize a Jazz Authentication Server (JAS).  That configuration is beyond the scope of this blog, but I highly recommend Shubjit Naik’s article on ELM and OAuth 2.0 Server to Server communication via Client Credentials Grant.

After following those instructions, your ELM Admin will have to provide you with key information to be used in this flow.

• grant_type
• client_id
• client_secret
• scope

Requesting a Token

As you may recall from the prior post, the RootServices document holds the information we need for OAuth 1.0a authentication; however, this does not hold true for OIDC.  You will need to get the URL for the “access token request” end point from your ELM application admin.  The endpoint can be found via the Server admin page, under the “The Authorization Server”

If we add /token to the end of the above URL, we now have the request Token API endpoint.

You can see the API is very simple.  We are passing the a grant request of “client_credentials”, with a client_id of “secret2” (which our ELM admin setup for us), a client_secret of “secret”, and asking for scope of “openid profile email general”.  These are all encoded in a url form.  The response that comes back is a simple json, as follows:

{
    "access_token": "6SnfUJgdMFHb4bj5Z6XO65Ay2bGidMfvDWmpgiLu",
    "token_type": "Bearer",
    "expires_in": 7200,
    "scope": "general openid profile email"
}

We receive a “Bearer” token, which expires in 7200 seconds.  It also confirms the scope we have asked for.  

Calling a protected API

Next we will call an API that requires authentication.  I will use the same API from the prior post, accessing a list of Project Areas on our server.

curl --location --request GET 'https://elmwb.com:9443/rm/process/project-areas' \
--header 'OSLC-Core-Version: 2.0' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer 6SnfUJgdMFHb4bj5Z6XO65Ay2bGidMfvDWmpgiLu’

As you can, all we did is change our call to provide the authorization via a new header. This is much easier (and quicker) than the steps required in OAuth1.0a.

If you are familiar with Postman, here are two files to help you process these same steps:

Postman Environment File – OIDC Demo Environment

Postman API Collection – OIDC Flow

That’s it!  If you have the opportunity on your server to setup the Jazz Authentication Server, I highly recommend that you utilize OIDC for your API which require authentication.