What is OAuth 2.0?
As per RFC 6749, The OAuth 2.0
authorization framework enables a third-party application to obtain limited
access to an HTTP service, either on behalf of a resource owner by
orchestrating an approval interaction between the resource owner and the HTTP
service, or by allowing the third-party application to obtain access on its own
behalf.
OAuth Roles
OAuth defines four roles:
1. Resource Owner: An entity capable of
granting access to a protected resource. When the resource owner is a person,
it is referred to as an end-user.
For example: A Facebook user is a
resource owner, when using any third party app he can accept or deny to give
access to its resources.
2. Resource Server: The server hosting the
protected resources, capable of accepting and responding to protected resource
requests using access tokens.
For example: Facebook.com is a resource server
3. Client: An application making protected
resource requests on behalf of the resource owner and with its
authorization. The term
"client" does not imply any particular implementation characteristics
(e.g. whether the application executes on a server, a desktop, or other
devices).
For example: Any app/game which you
use on Facebook.
4. Authorization Server: The server
issuing access tokens to the client after successfully authenticating the
resource owner and obtaining authorization.
For example: Microsoft Azure is an
Authorization Server.
OAuth Roles (Connecting from webMethods to Dynamics CRM)
OAuth Roles (Connecting from webMethods to Dynamics CRM)
·
Resource
Owner: Any Organization User/Administrator having access to Dynamics CRM.
·
Client
: webMethods Integration Server
·
Resource
Server : Dynamics CRM 2016
·
Authorization
Server/Identity Provider : Microsoft Azure Active Directory
OAuth
Flow (webMethods to Dynamics CRM)
Registering
Client Applications to Azure AD
In order to initiate the OAuth process with the
authorization server, the corresponding client application should be registered
with the authorization server, here in this case the client application has to
be registered with the Microsoft Azure Active directory.
The steps to register a client application with the
Microsoft azure and giving proper permissions to it, so that it can access the
desired APIs and applications is mentioned below.
Steps to register Client Applications to
Azure AD
Login to https://portal.azure.com/
Go to “Azure Active Directory” à “App registrations”
Click on Add link to add the new app
Give the app name
, application type and sign-on url (you can give any dummy url it’s just a
place holder) and click on create.
Now your app will be available on the registered app list , click on the App and then click on “All settings”
Note: Application id =
client id
Go to settings Reply URLs and add the reply URL, this URL will be called whenever the authorization end point will be invoked. Consider the reply URL as the URL of a callback service.
Go to settings Reply URLs and add the reply URL, this URL will be called whenever the authorization end point will be invoked. Consider the reply URL as the URL of a callback service.
Key generation, go to API Access à Keys and generate the keys. The key is generated only on clicking on save button. Store the key safe with you.
This completes the process of registering an app with
Microsoft Azure AD. Now we need to grant appropriate permissions to the
registered application so, that it can access or perform desired actions.
Steps to give Permissions to Registered
Application
Before we go on to the steps to add the required permissions
to the application. We need to know that there are two types of permission
which can be granted to the application. The two types of permissions are
mentioned below:
Delegated Permissions: Your application needs to access the web API as the signed-in user, but with access limited by the selected permission. This type of permission can be granted by a user unless the permission is configured as requiring administrator consent.
Application Permissions: Your application needs to
access the web API directly as itself (no user context). This type of
permission requires administrator consent and is also not available for native
client applications.
The steps to add required permissions to the application is
mentioned below:
·
Go to https://portal.azure.com/
, navigate to Azure Active Directory à
App Registrations à
click on your registered app.
·
Navigate to API Access à Required Permissions
·
Click on Add button , select the API and click
on select button
·
Select appropriate permissions and click on Done
button
In this way we can add required permission to the registered
app.
Authorization
Code Flow
The below diagram explains the flow for the
grant_type=authorization_code to get the access token.
Note: Here client is webMethods
Note: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-v2-protocols-oauth-code
Step 1
Call the authorization endpoint URI, provide the required
parameters. On calling the authorization endpoint, a pop-up appears asking the user/Administrator
to provide their consent to the application. The details of the authorization
end point URI is mentioned below.
To get the authorization end point, login to the https://portal.azure.com/ , go to Azure
Active directory à
Click on App Registrations à
Endpoint
You will get the authorization end point there.
The authorization endpoint looks like:
The parameters details for authorization endpoint is
mentioned below:
Parameter
|
Mandatory/ Optional/ Recommended
|
Description
|
tenant
|
Mandatory
|
The {tenant} value in the path of the request can be used to control
who can sign into the application. The allowed values are common,
organizations, consumers, and tenant identifiers. For more detail, see
protocol basics.
|
client_id
|
Mandatory
|
The Application Id that the registration
portal (portal.azure.com) assigned your
app.
|
response_type
|
Mandatory
|
Must include code for the authorization code flow.
|
redirect_uri
|
Recommended
|
The redirect_uri of your app, where authentication responses can be
sent and received by your app. It must exactly match one of the redirect_uris
you registered in the portal, except it must be url encoded
|
scope
|
Recommended
|
A value included in the request that will also be returned in the
token response. It can be a string of any content that you wish. A randomly
generated unique value is typically used for preventing cross-site request
forgery attacks. The state is also used to encode information about the
user's state in the app before the authentication request occurred, such as
the page or view they were on.
|
response_mode
|
Recommended
|
Specifies the method that should be used to send the resulting token
back to your app. Can be query or form_post.
|
prompt
|
Optional
|
Indicates the type of user interaction that is required. The only
valid values at this time are 'login', 'none', and 'consent'. prompt=login
will force the user to enter their credentials on that request, negating
single-sign on. prompt=none is the opposite - it will ensure that the user is
not presented with any interactive prompt whatsoever. If the request cannot
be completed silently via single-sign on, the v2.0 endpoint will return an
error. prompt=consent will trigger the OAuth consent dialog after the user
signs in, asking the user to grant permissions to the app.
|
login_hint
|
Optional
|
Can be used to pre-fill the username/email address field of the sign
in page for the user, if you know their username ahead of time. Often apps
will use this parameter during re-authentication, having already extracted
the username from a previous sign-in using the preferred_username claim.
|
domain_hint
|
Optional
|
Can be one of consumers or organizations. If included, it will skip
the email-based discovery process that user goes through on the v2.0 sign in
page, leading to a slightly more streamlined user experience. Often apps will
use this parameter during re-authentication, by extracting the tid from a
previous sign-in. If the tid claim value is
9188040d-6c67-4c5b-b112-36a304b66dad, you should use domain_hint=consumers.
Otherwise, use domain_hint=organizations.
|
In Order to
provide the consent to the app and generate the authorization code, the
following URL can be hit in the browser (as it is a get request)
?client_id=Registered application client ID
&redirect_uri=http://hostname:portNumber/rest/RESTResource/
&response_type=code
&response_mode=query
&scope=https://Resource.com/.access
Or
?client_id=
&redirect_uri=http://hostname:portNumber/rest/RESTResource/
&response_type=code
&response_mode=query
&resource=
Note: Line breaks have been added for better readability
Step 2
Once user enter the above URL in a browser, a pop-up will appear and the
user will be taken where in the user has to enter its credentials and then user
will be taken to the consent page where user has to approve the consent.
Step 3
Once the user provides the consent, the authorization code
will be sent to the redirect_uri configured on the App. The redirect_uri can be
configured to a webMethods REST service (GET verb) which will capture the
authorization code and store it somewhere.
In the above example, the following redirect_uri is
mentioned: http://hostname:portNumber/rest/RESTResource/
Note: Step 1, Step 2 and Step 3 are one time process for an application
Step 4
In this step, from the webMethods Integration server, we
will call the oAuth token endpoint(POST call ) to get the access token and refresh token
from the Microsoft azure .
The token endpoint looks like
The details of the parameters accepted by the token endpoint
for authorization_code flow is mentioned below
Parameter
|
Mandatory/ Optional/ Recommended
|
Description
|
tenant
|
Mandatory
|
The {tenant} value in the path of the request can be used to control
who can sign into the application. The allowed values are common,
organizations, consumers, and tenant identifiers. For more detail, see
protocol basics.
|
client_id
|
Mandatory
|
The Application Id that the registration
portal (portal.azure.com) assigned your
app.
|
grant_type
|
Mandatory
|
Must be authorization_code for the authorization code flow.
|
resource
|
Mandatory
|
The URI of the resource which we are trying to access
|
scope
|
Optional
|
A space-separated list of scopes. The scopes requested in this leg
must be equivalent to or a subset of the scopes requested in the first leg.
If the scopes specified in this request span multiple resource servers, then
the v2.0 endpoint will return a token for the resource specified in the first
scope. For a more detailed explanation of scopes, refer to permissions,
consent, and scopes.
|
code
|
Mandatory
|
The authorization_code that you acquired in the first leg of the flow
|
redirect_uri
|
Mandatory
|
The same redirect_uri value that was used to acquire the
authorization_code.
|
client_secret
|
Mandatory
|
The application secret that you created in the app registration
portal for your app. It should not be used in a native app, because
client_secrets cannot be reliably stored on devices. It is required for web
apps and web APIs, which have the ability to store the client_secret securely
on the server side.
|
After calling the token endpoint successfully, we will get
“access_token” and “refresh_token” values. The sample response is mentioned
below:
{
"token_type": "Bearer",
"scope": "user_impersonation",
"expires_in": "3599",
"ext_expires_in": "0",
"expires_on": "1482489503",
"not_before": "1482485603",
"resource": "https://Resource.com/",
"access_token": "0eXAiOiJKV1QiLCJhb",
"refresh_token": "RNYRQ3dhRSrm-4K-adpCJhKa50ykwJq7TvN7"
}
Step 5
Once we got the access_token values, we can use this access
token to call the Dynamics CRM web services.
Step 6
On access_token expiration, Use refresh_token value to
regenerate the new sets of access_token and refresh_token. The token endpoint
has to be called again with the different parameters to generate the access
token and refresh token.
The details of the parameters accepted by the token endpoint
for refresh_token flow is mentioned below
Parameter
|
Mandatory/ Optional/ Recommended
|
Description
|
tenant
|
Mandatory
|
The {tenant} value in the path of the request can be used to control
who can sign into the application. The allowed values are common,
organizations, consumers, and tenant identifiers. For more detail, see
protocol basics.
|
client_id
|
Mandatory
|
The Application Id that the registration
portal (portal.azure.com) assigned your
app.
|
grant_type
|
Mandatory
|
Must be refresh_token for the authorization code flow.
|
refresh_token
|
Mandatory
|
The value of the refresh_token generated in the earlier request
|
resource
|
Mandatory
|
The URI of the resource which we are trying to access
|
redirect_uri
|
Optional
|
The same redirect_uri value that was used to acquire the
authorization_code.
|
client_secret
|
Mandatory
|
The application secret that you created in the app registration
portal for your app. It should not be used in a native app, because
client_secrets cannot be reliably stored on devices. It is required for web
apps and web APIs, which have the ability to store the client_secret securely
on the server side.
|
Enjoy Reading , If you have any Question related to webMethods please comment below , I will try to answer the questions.Please Subscribe for latest update on the blogs
Get the list of question asked at experience level in IBM
ReplyDeletehttp://q4interview.com/technical_questions.php?tsid=15&off=0&rec=30
Nice Article to get understanding of OAuth with Azure and webMethods. Thanks a lot
ReplyDeleteHi,
ReplyDeleteactually i am fresher for this course but I just came across your Page and wanted to say that I’ve really enjoyed reading your posts Thank you(https://tekslate.com)
Thanks for the good Article , using this we are able to connect to Microsoft Dynamics 365 CRM without going through CloudStreams license .
ReplyDeleteIt's a good learning . Thanks a lot.
#API #Connectors #CloudStreams #webMethods #Dynamics365 #DyanmicsCRM . Still Works good . Thanks a lot Rakesh using this we are able to build our own flow services without using the Cloudstreams License . Also good materials are available on Microsoft documentation site .
ReplyDelete