Enabling OAuth2 to protect your Azure APIm

 


Protecting your Azure API is the most important part of your API design architecture. In fact, Azure API comes with a built-in authentication called as Ázure APIM Subscription, it comes with a subscription key, which you can see at under Azure API >> Subscription node:


 You can then send the subscription value as along with the header, while calling your API:

However there is yet another way of protecting your API: using oAuth2 tokens. This article shows how to implement the same.


Step 1: In your Azure portal >> Azure active directory >> App registration >> Register an App. Let us call it: client-app

Note down the Client Id, Tenant Id, Object Id. Create a Secret, give it some suitable time for validity. Note down its value.

Step 2: Click on the Endpoint: Copy the value of

a. OAuth 2.0 authorization endpoint (v2)

b. OAuth 2.0 token endpoint (v2)

c. OpenID Connect metadata document



Step 3: Come back to Azure active directory >> App registration >> Register an App. Let us call it: backend-app. Note down the Client Id, Tenant Id, Object Id. No need to create any secret here.

Step 4: Come back to Client-App --> click on API Permission --> Add a permission --> Come to 'My API' tab --> select backend-app --> Add permissions. Click on Grant admin consent to proceed:


 

Step 5: Come back to backend-App --> Click on Expose an API'. Copy the Application ID URI:


Click on Add a scope: give a name like: File.Read. Select 'Who Can consent'as Ádmins only. Give a name, a proper description, and then finally add. It will look like this now:



Step 6: Come back to Azure API --> Search for 'OAuth2.0 + OpenID Connect' --> Click on Add.

Give a name: DemoAPP. 

On Client registration Page URL field: give https://localhost

Authorization grant type: Authorization Code.

Authorization endpoint URL: Give the value from Step 2.

Authorization request method: GET + POST

Token Endpoint URL: Give the value from Step 2.

Default scope: from Step 5.

Client Id and secret: get from step 1.

Authorization code grant flow: Get it from 'OpenID Connect metadata document' of step 2.

Click Save to complete.

Step 7: Come back to your API setting, and select user Authorization as 'oAuth2':


Select/enter the value of the 'OAuth2.0 + OpenID Connect'' that you obtained from Step 6. Click on Save.

Now you have enabled Oauth2 authentication to Azure API. How to implant this in your Azure API?

Come back to Global policy (you can write on global policies to govern the overall behavior of your API, not just any particular operation) >> Use the following JWT policy -->

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized" require-expiration-time="true" require-scheme="Bearer" require-signed-tokens="true">
            <openid-config url="Get the value of your OpenID Connect metadata document from step 2" />
            <required-claims>
                <claim name="aud" match="all">
                    <value>App id of your backend-app</value>
                </claim>
            </required-claims>
</validate-jwt>
Click Save.

All done. Now how to see it working?
One way is to launch and test from Portal option of Azure API itself. 
Come to Azure APIm --> search for Portal overview >> click on 'Publish' --> 

Click on 'Developer portal' to launch your portal.  The portal launches in  Edit mode:



Click on Óperations icon to publish your changes.

Done?

OK....now the magic😉 

Copy the URL and paste it in an incognito mode browser. Here you can test your APIs --> Click on Éxplore APIs'.  

You would be able to see Echo API (the APIs which you have created in your Azure APIm). Click on the same. It will show you all the operations, avaialble. Click on any of them --> click on  Try it:



The Following screen/drop down dialog opens. 


If you select: no Auth and click on Send button, you will get the error:



Select Authorization -->  as Authorization_Code. Another window will pop up whereby it will ask you to key in admin credentials.

And walla!!! It has generated the bearer token for you:




Go down to bottom and click on send. It has given you the desired output:

This was just an example. You can use Outh2 with JWT token to test from a postman as well.

Outh2 is indeed a very smart (and cool) way of guarding your Azure APIs. 





Comments

Post a Comment

Popular posts from this blog

Make your menu items visible on main menu, conditionally,, using this cool feature of D365FO

Image
  Wassup guys? I am sure you must have encountered this situation where you needed to display your menuItems, on main menu, based on some condition, haven't you? This was only possible by using config keys and flights. Things get a bit tricky,  when suppose you have a requirement like this: you need to make it dynamic, by introducing a toggle switch on a field on a paremeter form.  Suppose on Accounts Receivables Parameters >> You have a field called ' Show US customer '. You have a requirement that says when you turn on this toggle, then only the menuItem ' Input SSN details ', under AR module. This is now highly acheivable by leveraging subscription to 'SysMenuNavigationObjectFactory' class, simply by saying a. Create a new class USMenuItemsVisibilityManager b. Copy the following method, with proper documentation (don't change signature/anything else) [SubscribesTo(classstr(SysMenuNavigationObjectFactory), staticdelegatestr(SysMenuNavigationObjec...
Read more

X++ : mistakes which developers commit the most

Image
   The most important thing is to remember where and when to write the code. a. Developers have an inherent habit of writing erratic select statements: select * from custTable where custTable.AccountNum == <SomeValue> Where in essence we need to make use of optimized choice of fields in the select statement. b. Making use of 'continue' keywords: While select custTrans where <someConditions> { if (cusTTrans.CustGroup != mappingTable.CustGroup) { continue; } } 'Continue' statements are precisely a very unhygienic way of designing your code. The above statement could have been easily ornamented by using exists/not exists joins. Using Continue statements would eventually result in a high performance impact. Also select statements should be made punctuated with a 'firstonly' clause -- just not from best practise standpoint, but also from performance considerations. c. Writing nested loops: This is a common mistake that perha...
Read more

Are you still using macros? Be sure you read this.

Image
  You still use a lot of macros in your code, don't you? Of course you should: Macros, as per Microsoft,  are p recompiler directives are processed before the code is compiled. The directives declare and handle macros and their values. The directives are removed by the precompiler so that the X++ compiler never encounters them. The X++ compiler only sees the sequence of characters written into the X++ code by the directives. However macros, are not quite recomended by Microsoft. They are slow, they can be subsequently deorectaed at any later time.  The Macros are  actually  a type of classes, only that they are not instantiated and not need be defined as classes. Hence runtime garbage collection could be a huge issue, consquently (a class when gets out of scope, gets garbage-collected owing to the destructor classes of DOT net instrumentation classes). Summing up, macrros are a bit old way of writing code. Use static classes instead. public static class MyIdenti...
Read more