Tag Archive: oauth

Two ways to integrate/federate applications with Azure AD:

Azure marketplace:


check if the application exists:

The Microsoft Azure Marketplace is an online store that offers applications and services either built on or designed to integrate with Microsoft’s Azure public cloud.

Else, how to configure single sign-on to applications that are not in the Azure Active Directory application gallery: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps

Authentication scenarios for Azure AD:


Applications integrated with Azure: the access via https://account.activedirectory.windowsazure.com/applications/default.aspx

Integrating applications with Azure AD: https://docs.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-integrating-applications


Identity hybrid ports and protocols:



Azure app gallery:


If not pre-packaged in Azure marketplace: Any app that supports SAML 2.0 can be integrated directly with an Azure AD tenant using these instructions to add a custom application.

Provide credentials for a test tenant or account with your application that can be used by the Azure AD team to test the integration.

Provide the SAML Sign-On URL, Issuer URL (entity ID), and Reply URL (assertion consumer service) values for your application, as described here. If you typically provide these values as part of a SAML metadata file, then please send that as well.

Provide a brief description of how to configure Azure AD as an identity provider in your application using SAML 2.0. If your application supports configuring Azure AD as an identity provider through a self-service administrative portal, then please ensure the credentials provided above include the ability to set this up.

Configuring single sign-on to applications that are not in the Azure Active Directory application gallery:



Sign On URL (SP-initiated only) – Where the user goes to sign-in to this application. If the application is configured to perform service provider-initiated single sign on, then when a user navigates to this URL, the service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD Access Panel. If this field is ommited, then Azure AD will instead perform identity provider -initiated sign on when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL (copiable from the Dashboard tab).

Issuer URL – The issuer URL should uniquely identify the application for which single sign on is being configured. This is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s SAML documentation for details on what it’s Entity ID or Audience value is. Below is an example of how the Audience URL appears in the SAML token returned to the application

Reply URL – The reply URL is where the application expects to receive the SAML token. This is also referred to as the Assertion Consumer Service (ACS) URL.








When Kerberos was chosen to be AD’s authentication protocol in the mid- to late-1990s, the World Wide Web was a shadow of what the Internet offers today. Although the Kerberos ticket contained an encrypted password hash that could be attacked, there wasn’t any substantial requirement to provide support outside the highly protected corporate firewall.

The rise of cloud services is changing many aspects of our lives, and these services don’t support external authentication via Kerberos because of that password vulnerability. If a web service uses standards, it handles claims-based authentication using SAML 2.0 or, increasingly, OAuth 2.0 and OpenID Connect. Microsoft’s own Azure Active Directory doesn’t use Kerberos; it supports SAML and OAuth 2.0 as its authentication protocols.


Comparing oauth with ws-fed and SAML: https://blogs.technet.microsoft.com/askpfeplat/2014/11/02/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/



Wikipedia Article: OAuth



OAuth in details

OAuth is an authorization method to provide access to resources over the HTTP protocol.


OAuth2 can be used for authorization of various apps (server/browser/mobile)and desktop applications or manual user access.

The general way it works is allowing an application to have an access token (which represents a user’s permission for the client to access their data) which it can use to authenticate a request to an API endpoint.

Oauth 2 flow

A sample OAuth flow: Facebook

OAuth versions

There are two versions of OAuth authorization OAuth 1 (using HMAC-SHA signature strings) and OAuth 2 (using tokens over HTTPS).

Note: SoapUI currently only offers Oauth2 authorization.

OAuth 2 terms

Conceptually, OAuth2 haas a few components interacting: The resource server (the API server) contains the resources to be accessed. Access tokens are provided by the authorization server (which can be the same as the API server). The tokens are provided by the resource owner (the user) when accessing the resources. Similarly, an application using the credentials, and the API is called client.

End Points

The token Endpoint is used by clients to get an access token (and optionally refresh token) from the authorization server.

Note: When using implicit grant, this endpoint is not used. Instead the access token is sent from the authorization endpoint directly.


The two token types involved in OAuth 2 authentication are Access Token and Refresh Token.

Access Token

The access token is used to for authentication and authorization to get access to the resources from the resource server.

Refresh Token

The refresh token normally is sent together with the access token.

The refresh token is used to get a new access token, when the old one expires. Instead of the normal grant type, the client provides the refresh token, and receives a new access token.

Using refresh tokens allows for having a short expiration time for access token to the resource server, and a long expiration time for access to the authorization server.

Token Types

Access tokens have a type, which defines how they are constructed.

Bearer Tokens

The bearer tokens use HTTPS security, and the request is not signed or encrypted. Possession of the bearer token is considered authentication.

MAC Tokens

More secure than bearer tokens, MAC tokens are similar to signatures, in that they provide a way to have (partial) cryptographic verification of the request.


Methods to get access tokens from the authorization server are called grants. The same method used to request a token is also used by the resource server to validate a token.

The four basic grant types are Authorization Code, Implicit, Resource Owner Credentials and Client Credentials.

Note: SoapUI currently only offers the grant types Code Grant and Implicit.

Authorization Code

With authorization_code grant, the resource owner allows access. An authorization code is then sent to the client via browser redirect, and the authorization code is used in the background to get an access token. Optionally, a refresh token is also sent.


The implicit grant is similar to authorization code, but instead of using the code as an intermediary, the access token is sent directly through a browser redirect.

Not yet in SoapUI Resource Owner Credentials

The password/Resource Owner Credentials grant takes the uses the resource owner password to obtain the access token. Optionally, a refresh token is also sent. The password is then discarded.

Not yet in SoapUI Client Credentials

In client_credentials grant mode, the client’s credentials are used instead of the resource owner’s. The access token is associated either with the client itself, or delegated authorization from a resource owner.

Grant Type Extensions

OAuth has a mechanism for extending grant types as a bridge to other authorization frameworks, or for specialized clients.

Extension grants are used by clients through an absolute URI together with a grant_type parameter and by adding any additional parameters necessary to the end point.


In OAuth 2, the scope is a way to restrict access to specified areas. A common way of handling it is with a comma-separated or space-delimited list of strings, where each string indicates an areas of access.


ADFS 2016 and OAuth/OpenID connect: