I’m struggling with configuring Azure AD B2C so it supports: Multitenants and external identity providers at the same. I have a SPA application (in Angular, using MSAL.js) with .NET backend (.NET 4.8). I have configured “Identity providers” and followed a tutorial from active-directory-b2c-custom-policy-starterpack sample. My app is registered in Azure. It has Authentication links configured (I tried https://xxx.b2clogin.com/xxx.onmicrosoft.com/oauth2/authresp for both WEB and SPA authentications). It has API permissions to Microsoft Graph.
No success so far. Current error: AADB2C90273: An invalid response was received : 'Error: unsupported_response_type,Error Description: AADSTS70005: 'The application requested an unsupported response type '' when requesting a token.
I suspect that the custom policy XML file is misconfigured. Unfortunately, what I miss is a general overview how the solution supposed to work. That’s why I have the following questions. I’ll applicate any additional hints on the topic.
Questions:
When user authenticates with external identity provider (e.g., Facebook, LinkedIn, external SSO) will an account be created for him in Azure Active Directory B2C?
Multitenant administrators have to add permissions to their users in order to use my app? How can they do that?
AADSTS70005: 'The application requested an unsupported response type '' when requesting a token. – where can I configure the response type for “this” application?
Based on the error AADSTS70005, it shows that this can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
Workaround is to allow all user consent for apps from the “consent and permissions” blade of the enterprise applications.
Ref: Configure User consent settings:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent?tabs=azure-portal#configure-user-consent-settings
Related
I am getting the error,"aadb2c90243: the idps client key/secret is not properly configured" on android application that I have setup for authentication with Azure ADB2C. The error occurs when I press on the Microsoft social login that is amongst my social logins in the specified user flow. Any ideas?
• Please check whether your OAuth redirect URIs are correct or not, also, they should not be expired or invalid, i.e., they should be ‘ https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp ’ or ‘ https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp ’. There should be no trace of ‘login.microsoftonline.com’ in the redirect URIs in the android version of the app configured for logging into the Microsoft personal accounts.
• Please check the ‘APP ID’ and the corresponding ‘App secret’ created for logging into the Microsoft social accounts through your app page. As it may be conflicting to login with the Microsoft social personal accounts using the Azure AD B2C authentication. Thus, would suggest you to please check the redirect URIs for the app configured in Azure AD B2C authentication user flow.
Please refer the below link for more details: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-microsoft-account?pivots=b2c-custom-policy
We need to configure okta as IDP for azure ad applications. For example: When a user tries to access the enterprise application, they'll be challenged with a login page, which will be validated by OKTA. Post this authentication, the authorization will be handled by Azure and upon successful authorization, user will be shown a landing page of the application.
We have referred below links as reference for setup:
https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp
https://developer.okta.com/docs/guides/custom-url-domain/overview/
What we did so far?
Registered company "example.com" in okta. By default okta configures it as "example.okta.com"
Registered custom domain "id.example.com". Our okta instance is accessible using this domain
Created an enterprise SAML app (which also exist in Azure AD) in OKTA
Exported OKTA IDP metadata
Now, we are trying to import this IDP metadata as external identity provider in AAD. But it fails with below error, if we map example.com or id.example.com as domain name of federating idp. Because of these errors we’re unable to setup the custom domain of federated IDP(OKTA). Please assist us on the approach for the same.
Error Messages:
For domain as "id.example.com"
Failed to add a SAML/WS-Fed identity provider.This direct federation policy does not pass one or more requirements. Go to aka.ms/b2b-direct-fed to learn more.
For domain as "example.okta.com"
Failed to add a SAML/WS-Fed identity provider.This direct federation configuration is currently not supported. The authentication URL must match the domain for direct federation or be one of the allowed domains. Go to aka.ms/b2b-direct-fed to learn more.
You need to go through the Azure AD federation compatibility list to learn about how to federate an Azure AD tenant with a 3rd party IDP like Okta and others.
#Kalyan Krishna
Hi,
Thanks for the reply. We have already gone through the documentation. OKTA is listed down as one of the supported 3rd party federated IDP that Azure supports. We referenced the MS docs and tried to configure, but we observed Azure AD doesn't support external IDP(OKTA) configuration with custom domain. It throws error as mentioned in the above post. So, we tried to configure the federated domain as ".okta.com" (including other IDP metadata details). It worked then, and for authentication AZ AD is getting redirected to OKTA. SP authentication flow works fine when myapps URL is appended with tenant ID, but while testing IDP initiated SSO it fails.
IDP initiated SSO fails with OKTA as an IDP in Azure
i am currently implementing a "System-of-Systems" authentication architecture in Azure Active Directory B2C (AAD B2C). In these scenario there is an initial SSO application that redirects the user to a general dashboard. The dashboard should enable the user to use additional services (service applications). (For example a tile view)
To use these additional services, the user must grant explicit permission for each external service. With this delegated permissions, the user authorizes the service to access certain data (for example, IoT data or personal data).
These AAD B2C application is characterized in this scenario by a client and backend application (api) (for each service). The client application contains scopes (delegated permissions) from the backend application, which are stored as a JWT validation - Policy in each Azure API Management endpoint.
Authentication against these assigned backend scopes already works with the Microsoft Login Provider (Identity Provider), but not with the local Identity Provider (for E-Mail).
Here: My Scenario
I changed the access level from Admin to User in the application manifest: (Here)
Microsoft Access Panel (works here)
My Problem the Local Idenitity Access Panel for users (that doesn't works) -> should look like this: Microsoft Docs (consent dialog)
For the following request:
https://[tenant].b2clogin.com/[tenant].onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_SignUpAndSignIn&client_id=xxxxx-xxx-xxxxxx&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid https://[tenant].onmicrosoft.com/backend/Backend.Read&response_type=id_token token&prompt=login
... I always get the following error message:
AADB2C90205: This application does not have sufficient permissions against this web resource to perform the operation.
The approval framework is not displayed for the user, therefore the request is rejected by insufficient permissions.
Do you know how to solve this problem? Are there any walkarounds or configuration options?
Thank u & Best regards
You missed some scopes of your application. Navigate to Applications (Legacy) -> API access, the scope need to add all scopes that you select.
The scopes that you defined are in Published scopes, you could add Full Scope Value in the URL.
This is my URL, and it works well:
https://[tenant].b2clogin.com/[tenant].onmicrosoft.com/oauth2/v2.0/authorize?p=B2C_1_SignupSignin&client_id=xxxx&nonce=defaultNonce&redirect_uri=https://jwt.ms&scope=openid offline_access https://[tenant].onmicrosoft.com/api/demo.write https://[tenant].onmicrosoft.com/api/demo.read https://[tenant].onmicrosoft.com/api/user_impersonation
&response_type=id_token token&prompt=login
For more details, you could see a tutorial and implicit flow.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas
I am developing a web application with Windows Azure Active Directory (WAAD) authentication support. In WAAD I added a user which already has a Microsoft Account.
I use SAML 2.0 protocol for authentication request.
In my app upon accessing a protected resource, I redirect the user to:
https://login.windows.net/<id>/saml2/SAMLRequest=...&RelayState=...
This is URL I copied from the WAAD management console:
The decoded SAML token looks like:
<samlp:AuthnRequest ForceAuthn="false"
ID="b6f579bb-c7fc-49b1-a8f1-bbe2ad99da5d"
IsPassive="false"
IssueInstant="2014-07-25T06:38:11.303Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2p:Issuer>....onMicrosoft.com</samlp:Issuer>
<saml2p:NameIDPolicy AllowCreate="true"/>
<saml2p:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml2p:RequestedAuthnContext>
This is working great, I am redirected to
https://login.microsoftonline.com/...
https://login.live.com/...
However, upon autheticating with a Microsoft Account user (which is also imported into WAAD), I get this error message:
ACS20031: Sign-in with LiveId is not supported for this application.
What am I missing?
On the WAAD web admin console I did not see such a setting. I tried both Single Tenant / Multitenant options
Is there a possibility to login with a simple WAAD user (not LiveId) with foobar#<tenantid>.onmicrosoft.com ?
To my knowledge no.
Up to today, the only way to get users signed-in with Live ID to your Application are the following:
Use Azure Active Directory Access Control Service (or better known as ACS)
Use the LiveID Web Authentication SDK
Use the Azure Active Directory with a remark. The remark is:
** You can only use LiveID to sign-in with Azure Active directory, if you first provisioned that user in your directory tenant. Provisioning happens when you create a new user in your Azure Active Directory Tenant and in the process of adding, add it as a LiveID e-mail. Then you will have this user in your AAD but marked as "Sourced From" -> "Microsoft Account":
The type of federation you are trying to enforce currently only works for Microsoft Internal applications, and not for customers. The only federation service that currently works for Customers is the Access Control Service.
Here you can read a bit about the future of ACS and the plans to merge these federation capabilities into next versions of AAD. But we still haven't got to that future.