Skip to content

Microsoft Entra ID#

This strategy accesses an Active Directory structure stored directly in the Microsoft Azure cloud. The OAuth 2.0 specification is a flexible authorization framework that describes a number of methods (grants) for a client application to acquire an access token (which represents the permission for a specific client to access their data). This token can then be used to authenticate a request to an API endpoint.

Simply put, the flow can be summarized as follows:

A client application makes an authorization request to an authorization endpoint, receives a short-lived authorization code, makes a token request to a token endpoint using the authorization code, resulting in an access token. If the access token expires, the client can request a new token from the token endpoint by specifying a refresh token as the grant type.

Authorization Flow Refresh Token

For additional security, client applications can use the OAuth 2.0 Authorization Code Flow with an enhancement mechanism known as Proof Key for Code Exchange (PKCE) to prevent man-in-the-middle attacks and ensure that URL redirects are not intercepted. This mechanism introduces a secret called the Code Verifier, created by the calling application, which can be verified by the authorization server. Moreover, the application creates a transform value of the Code Verifier called the Code Challenge and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier.

Authorization Flow PKCE

Furthermore, there are two options for configuring the application:

  1. Create a custom package to define the client_secret (as it is not yet possible to define the secret through DevOps Center installations).

    Note

    Defining the client secret via DevOps Center will be possible in a future version.

  2. Configure the application as a Mobile and desktop application to use PKCE authentication.