Azure logic app authorization with custom policy issuer - azure

This article states that an issuer has to be login.microsoftonline.com or sts.windows.net when securing a logic app. I have a custom policy where the issuer of the access token is https://{TENANT}.b2clogin.com/{TENANT}/v2.0. How can I secure a logic app using the access tokens that come back from my B2C custom policy?

Related

AzureADB2C Client Credentials Grant with Client Assertion as Opposed to Static Secret

I have a requirement to provide API to our consumers. The intention is to secure the API using AzureAD B2C - Client Credential Grant flow.
I have created a custom policy on B2C tenant that provides the access token. Things work fine with the clientId and Secret authentication method.
I now want to secure the OAuth2 conversation further by allowing the client to use the signed client_assertion as opposed to static client secret using their protected key. I have uploaded the public portion of the key into the relevant app registration.
Unfortunately, consuming the /token endpoint with the signed client_assertion results in an error.
REQUEST
https://tenant.b2clogin.com/tenant.onmicrosoft.com/b2c_1a_demo_clientcredentialsflow/oauth2/v2.0/token
grant_type=client_credentials&scope=https%3A%2F%2Fapi%2F.default&client_id=d5339984-e6c7-457a-9ef9-21fb6e3e6c59&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJo
RESPONSE
HTTP/1.1 400 Bad Request
{"error":"invalid_request","error_description":"AADB2C99027: Policy 'B2C_1A_Demo_ClientCredentialsFlow' does not contain a AuthorizationTechnicalProfile with a corresponding ClientAssertionType.\r\nCorrelation ID: 5eb76fa5-c919-4877-a722-0d38408e18c6\r\nTimestamp: 2023-01-19 07:38:25Z\r\n"}
Can someone please tell me if B2C is intended to support client assertions? Metadata JSON on the policy returns only the following two authentication methods:
"token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ]
Is it possible to include private_key_jwt as a supported authentication method using custom policy configuration? Is it possible to configure the AuthorizationTechnicalProfile for the policy with a corresponding ClientAssertionType?
I hope that I have explained the problem well enough.
I have tried various strategies, incluling the use of AAD token endpoint, login.microsoftonline.com with the B2C tenant Id. Using that endpoint, the custom policy on B2C is completely ignored, therefore generating a vanilla token with none of my curated claims.
TLDR: As of June 2022, Azure AD B2C does not support client assertions.
This issue on Github asks for documentation for error number AADB2C99027. In the course of the discussion, a member of the team states
Unfortunately, we decommissioned client_assertion flow because it didn't follow OIDC spec – So we shouldn't be documenting the error.
From that, I take that there are no plans to support client_assertion flow.

getting custom claims in Access Token for Client Server application in Azure AD?

We have a client-server application that targets enterprise use cases mostly. We want to test if Azure AD is a valid IDP for our application that now supports authorization code flow but may be developed to support for authorization code with PKCE.
Our requirement is that we need 'preferred_username' and 'groups' as claims in the jwt based access tokens. The client application is a desktop based app (Win & linux) that authenticates users using any IDP speaking authorization code flow.
For POC, I used a trial account from Azure ad with default set of users in azure ad. Created security groups in the Azure Ad portal and added users to those groups. I registered apps as desktop/mobile based platforms and with an arbitrary redirect url. Under Token configuration, I added 'preferred_username' in access token as optional claim and 'groups' as part of both ID and Access Tokens.
I have set following in the application manifest:
"accessTokenAcceptedVersion": 2,
But these claims are never listed in the access tokens but only appear in ID token.
Is it possible to get these claims in access tokens, so the resultant access tokens can be used by our application?
Tried: Authorization code flow with PKCE for desktop/mobile app.
Expected claims preferred_username and groups in jwt Access token.
TLDR; Following below article, I am expecting an Access Token for my server:
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-your-web-api
In my understanding:
Client App ---> Client App on Azure (with scope perms to Web Api)
Server App ---> Web API App on Azure (exposing scope)
CLient App permissions
Also, I think I am dealing with 2 issues here:
Get Custom Claims in Access Token with Authorization code (or Auth code + PKCE)
Access Token should be meant for my application ( and not MS Graph)
When creating a App registration, you have to add
groupMembershipClaims": "SecurityGroup",
To your manifest to access the security groups
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims
If you creating a enterprise application you can add Attributes & Claims within the single sign on settings.

Azure AD token validation - why validate issuer?

I have an API service that uses Azure AD tokens for authentication and authorization. I plan to use https://github.com/AzureAD/passport-azure-ad library for this and need to use BearerStrategy - https://github.com/AzureAD/passport-azure-ad#42-bearerstrategy. I'm confused by the validateIssuer property.
validateIssuer and issuer configurations need to be used together if I understand the docs correctly. issuer is a URL that contains the tenant id and the AD version(1 or 2) used to issue the token.
As the API service who will validate token, why would the API service care about the AD version that was used to issue the token? And hence why would it validate the issuer url, when it should care only about the tenant id? I'm trying to understand why must the entire issuer url be verified and not just the tenant id.
In the API service the validators are defined in the library source file like Microsoft.IdentityModel.Tokens/Validators.cs. which validates the token based on the token validation parameters (Issuer, ValidateIssuer, signature etc..).
The issuer contains the URL for the actual tenant with the v1.0 and v2.0 endpoints.
Tokens always needs to match the endpoint they're requested from, and the tokens always match the format expected by the Web API your client will call using that token.
Why You need to validate the issuer because many services can generate tokens but you only want to trust certain source(s).
If we leave ValidateIssuer then middleware will not try to validate the issuer tenant and it would effectively mean that your application is open for anyone with a user in Azure AD.
For more information about the token validation please refer the documents Validateissuer and issuer

Azure B2C flow validating business logic through an Oauth2 API protection

We are creating an Azure B2C custom Policy and we would like to know if there is any way to call an external API that is protected by an oauth2.
I saw that is only possible to call an API that has Basic or Certificate validated.
Basic: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw-secure-basic
Certificate: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw-secure-cert

Azure AD OAuth Client Credentials Grant flow

Trying to set up Azure AD OAuth client credentials grant flow for my web api. I'm following the document in https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow. I have to expose my API to a 3rd party. I've created the APP in Azure AD (this is for the client that is requesting my API), generated the secrets and was able to get a response from oauth2/token endpoint. My questions are below:
What is the best way to validate the token? Is it by passing the JWT
(bearer token) as a HTTP header to my API, and then using the SDK to
validate the token
(System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler)? I'm using
C#.
What is the significance of Azure AD -> App Registrations -> "My
API App" -> under Manage, Expose an API? It has an option to
"Authorize client applications". How could I use this feature to
conditionally block and approve the client applications?
I will have to share the secret, client id and the App Id Uri with the 3rd party for them to generate the token and I will validate the token when I receive it.
You're on the right track.
This answer, Azure AD OAuth client credentials grant flow with Web API AuthorizeAttribute Roles, will walk you through one way to do this, using the roles claim in the token to authorize the call.
You will need to:
define roles
create an App registration for each 3rd party
assign their application to your desired roles
You can then use the AuthorizeAttribute to map which roles can execute which controllers/actions, like so:
[Authorize(Roles = "Reader,Requester,Editor,Approver,Administrator")]
Token validation
Once you complete token obtaining flow, you receive a JWT bearer access token. From token consuming end (your service), you need to perform a JWT validation. This is done by validating JWT signature and Claims. One of the most important claim you validate is the audience (aud) claim which must be the identifier (ex:- your service's URL, an ID) unique to token receiving service. Where you register this ? That's your second question.
Please read through MS's guide on token validation which explains key points - Microsoft identity platform access tokens
Service registration
This is where you register valid token receivable endpoints (ex:- your api app). If you check your token request, you provide resource parameter which must match to registered identifier. This allows Azure to validate the token request and issue an access token the mentioned resource. You find this as aud claim in the token. Hope you got the connection now.
App secret
No, only the token obtaining party require the client credentials. Your API or any token consuming party does not need the secret. They only require a valid access token and token signing certificate details. certificate details are exposed at jwks_uri in openid-configuration endpoint.

Resources