Tag Archives: Key Vault

Blog Series – Power’ing up your Home Office Lights: Part 4 – Using Logic Apps to Get Access Token and Renew Access Token if needed

3 Replies

This blog post is part of the Blog Series: Power’ing up your Home Office Lights with Power Platform. See introduction post for links to the other articles in the series:
https://gotoguy.blog/2020/12/02/blog-series—powering-up-your-home-office-lights-using-power-platform—introduction/

After building the Logic App in part 3 that will authorize and get access token via Oauth2, we will now create another Logic App that will retrieve the Bearer Token from the Key Vault secret, and renew the Token using Refresh Token whenever it is expired.

Here is a short video where I walk through that Logic App scenario:

Create the Logic App and HTTP Trigger

The first thing you need to do, is to create a new Logic App in your Azure subscription. Select the Resource Group you have contributor access to, and give the Logic App a suitable name, as per your naming guidelines. This is the Logic App I created in my environment:

Add a HTTP request trigger for this Logic App as well:

In the Logic App Designer, make sure you hit Save on the Logic App before the next step. You will now be shown the URL, but first go down to the “Add new parameter” and select Method and GET for method. This way your Logic App will trigger on HTTP GET requests.

Adding Logic App Identity and Key Vault Access

As this Logic App also will request secrets from Key Vault, we will need to add a Managed Service Identity and add that to the Key Vault access policy.

Go to Identity settings, and set the System assigned Identity to On:

Next, go to your Key Vault and under Access policies, add the the newly created Logic App with the following Secret permissions (Get, Set, List):

Add Actions for Getting or Renewing Bearer Token

The actions in this Logic App will retrieve the Bearer Token from the Key Vault and return the Access Token as a Response. If Token is expired, it will be renewed using the Refresh token.

Start by adding a HTTP request, and get the Secret for the Bearer Token like the following:

Next, add a Compose action, getting the outputs from the Get KV Secret Bearer Token action. This secret was stored as a Json Object, but will be returned as a String, so I have used the following custom expression to convert to Json:

json(outputs('Get_KV_Secret_Bearer_Token')?['body/value'])

Next, add the following Compose actions for getting the timestamps in Ticks, and converting to Epoch. See the previous blog post for explanation of why this is necessary, but we need to do this to be able to calculate wether the secret is expired or not:

For your convenience, I’ve added the custom expressions as comments to the actions above, or you can copy it from below:

ticks(utcNow())

ticks('1970-01-01T00:00:00Z')

div(sub(outputs('GetNowTimeStampInTicks'), outputs('Get1970TimestampInTicks')), 10000000)

Next, add a Condition action. Here we will check if the expiry date time of the secret is greater than the current calculated timestamp in Epoch:

Use the following custom expression for getting the “exp” attribute from Key Vault Secret:

outputs('Get_KV_Secret_Bearer_Token')?['body/attributes/exp']

If the secret hasn’t expired, we will return the access token as a Response action as shown below. Note that I will only return the access_token, not the complete Bearer Token stored in the Key Vault secret, as this also contains the refresh_token. The reasoning behind this is that the calling clients (users from PowerApps/Automate) only need the access_token.

As you see from above, I’ve built a Json body and schema for the response, and the custom expression returing the value of access_token is outputs('Compose_Bearer_Token')?['access_token'].

On the False side of the Condition, meaning that the Secret is expired, we will have the logic that renews the Bearer Token. First add two HTTP actions, for getting the Client Id and Client Secret from Key Vault:

Next, add another HTTP action, using Method POST we will send a request to the oauth2/refresh endpoint at Hue Remote API:

The refresh_token need to be sent in a Request Body, using the expression: outputs('Compose_Bearer_Token')?['refresh_token']

Remember to set Content-Type: application/x-www-form-urlencoded. And Authentication Type should be set to Basic, using the retrieved Client Id and Secret from Key Vault as username and password.

Refreshing the Token correctly will return a new Bearer Token. We now need to get and convert the time stamps to Epoch integer, to calulate when the Access Token expires. This is the same process as we used in the Logic App “logicapp-hue-authorize” in part 3 of this blog series. Add 3 new Compose actions like below:

For your convenience, here are the custom expressions used for the above actions:

addSeconds(utcNow(), int(body('Post_Refresh_Code_with_Basic_Auth_to_Update_Access_Token')?['access_token_expires_in']))

ticks(outputs('AccessToken_Expires_Utc'))

div(sub(outputs('GetTimestampInTicks'), outputs('Get1970TimestampInTicks')), 10000000)

Next step is to update the Bearer Token Secret in Key Vault with the new Token we received now and the new expiry date. Add a HTTP action like below:

We can now return the access_token using the HTTP action like below:

The last action we need to add is a default response if any accest_token could not be returned. This is important as we are going to call this Logic App using Power Automate Flows, and we need to have a response for any scenario. Add this after the condition action like below:

For the Null Response action, change the Configure run after setting like the following:

That should be it. Remember to secure outputs for any actions that return credential information:

Verify Logic App

We can now test the Logic App. You can use Postman, Invoke-RestMethod in PowerShell, or just run in the Browser your Logic App Http Trigger Url:

This should return your Access Token:

Looking at the Run History for the Logic App, we should see a sucessful run:

Summary and Next Steps

That should conclude this blog post. In this post, and the previous, we have built the logic behind authorizing and getting the Bearer Token for Philips Hue Remote API, as well as providing and refresh the Token when needed.

In the next part we are going to start building the solution in Power Automate. Thanks for reading, see you in the next part!

Blog Series – Power’ing up your Home Office Lights: Part 2 – Prepare Azure Key Vault for storing your API secrets

1 Reply

This blog post is part of the Blog Series: Power’ing up your Home Office Lights with Power Platform. See introduction post for links to the other articles in the series:
https://gotoguy.blog/2020/12/02/blog-series—powering-up-your-home-office-lights-using-power-platform—introduction/

Continuing on Part 1, where we created an App Registration for Hue Remote API, I will need a secure place to store the App credentials like Client ID and Secret. I will also need to store the Access Token and Refresh Token, so that I can retrieve it when I need to call the Hue Remote API, and use the Refresh Token to renew the Access Token when it expires.

To start with, here is a short video where I explain the concept:

Choosing Azure Key Vault as Secret Storage

Client ID and Secret from the App registration are credentials that needs to be protected from unauthorized access. Likewise, if unauthorized users get hold of your Access Token, they can access your Hue Bridge remotely and create user access for themselves to your Hue Lights.

If you are planning to build this solution only for yourself, and no other users will share your Hue Power Apps and Flows, then you can store the credentials and tokens in a personal storage, for example in a SharePoint Online List. Just make sure that this resource never will be shared with other users internally, or externally. This would also be a logical choice if you don’t have access to an Azure subscription for yourself.

In my case, I wanted to be able to share the user part of the solution with other users, while making sure that my credentials and tokens were as protected as possible. So I decided to create some logic around that in Azure, and to store my secrets in Azure Key Vault.

Setting up Azure Resources for Key Vault

You will need access to an Azure Subscription to do this part. Your organization might provide you with access to a subscription, or there are several pathways to starting with Azure for free, amongst others Visual Studio subscription, Azure for Free, Azure for Students to name a few.

At a minimum you will need Contributor access to a Resource Group, where you can deploy the following:

  • Azure Key Vault resource for storing secrets for Power Platform and Hue Remote API.
  • Adding the secrets necessary for the solution.
  • Access policy that allows you, and later the Logic Apps access to get, set and list secrets from the Key Vault.

In your resource group, create a new Key Vault. The name needs to be globally unique, so it makes sense to use any naming convention:

For the purpose of the Hue Remote API, you will need to create the following 3 secrets:

The “secret-hue-client-id” and “secret-hue-client-secret” are created manually with the client id and secret from the Hue App registration.

The “secret-hue-bearer-token” will be populated via the Logic App we will look into in a later part in this blog series. Note that this secret has an expiration date, which is when the token expires. I will get into that later as well.

Managing Access to the Key Vault

You need to configure the Key Vault access policy so that you, and any services that interact with the Key Vault have the right access to get, set or list secrets.

In this case, I have configured my Hue Logic Apps with access via Managed Service Identity (MSI), at this point you might not have these in place yet, but we will get there also in a later part:

With that we can conclude this part, in the next part of the blog series we will start looking into the Logic Apps for Hue authorization and managing access token.

Thanks for reading, see you in the next part 🙂