How does registering my FlightDeck 365 Module in Azure work with Oauth? (4380864)

Configuring authentication schemes can be down right confusing. The following article is designed to shed light on the complex scenarios of how and why registering the module works.

n/a

Having the client ID, client secret, and tenant ID of the FlightDeck 365 Module configured in your application enables the following steps in the OAuth 2.0 authorization process:

1. Initiate Authentication:
   • Your application uses the client ID to identify itself to Azure AD when requesting access to a protected resource (e.g., a user’s data or an API).
   • The tenant ID specifies which Azure AD directory (tenant) is handling the authentication, ensuring the request is sent to the correct authority (e.g., your organization or a multi-tenant environment).
2. Request an Authorization Code (for Authorization Code Flow):
   • Your app redirects the user to Azure AD’s authorization endpoint, including the client ID and tenant ID in the request URL.
   • The user signs in and consents to the permissions your app requested (configured in the "API permissions" step during registration).
   • Azure AD returns an authorization code to the redirect URI you specified during app registration.
3. Exchange Authorization Code for Access Token:
   • Your app sends a request to Azure AD’s token endpoint, including:
     • The client ID to identify your app.
     • The client secret to authenticate your app securely (proving it’s really you).
     • The authorization code received in the previous step.
   • Azure AD verifies these and returns an access token (and optionally a refresh token).
4. Access Protected Resources:
   • Your app uses the access token to call the target API (e.g., Microsoft Graph) on behalf of the user or as the app itself, depending on the permission type (delegated or application).
   • The tenant ID ensures the token is scoped to the correct directory.
5. Token Refresh (Optional):
   • If a refresh token was issued, your app can use it (along with the client ID and client secret) to request a new access token when the current one expires, without requiring the user to sign in again.

Summary

With the client ID, client secret, and tenant ID configured, your app can:

• Identify itself to Azure AD.
• Authenticate securely to obtain tokens.
• Request user consent for permissions.
• Access protected resources via APIs.
• Maintain access by refreshing tokens.

This setup supports OAuth 2.0 flows like the authorization code flow (common for web apps) or client credentials flow (for app-only access).