I thought this would be a simple Google but I cant seem to find an answer.
When an invitation email is sent from Azure AD B2C (Active Directory Business to Consumer), how long is the emailed link valid for before it can no longer be redeemed?
Is this configurable anywhere?
Thanks
To invite a user, from the application, we will type the user's email address and click Send invintation. The application sends a sign-in link (with a id_token_hint). User clicks on the link, that takes to user to Azure AD B2C policy.
The key to sending data to Azure AD B2C custom policy is to package the data into a JWT token as claims using id_token_hint. In this case, we send the user's email address to Azure B2C. Sending JWT token requires to host the necessary metadata endpoints required to use the "id_token_hint" parameter in Azure AD B2C. The id_token_hint must be a valid JWT token. The token contains the claims that are mandatory.
So inside the token we have claim called exp(Expiration time): The time at which the token becomes invalid, represented in epoch time. Azure AD B2C validates this value, and rejects the token if the token is expired.
Token Format and claims
Reference
Related
Once the admin has consented to my daemon app he is redirected back to my website, but I want to be extra safe and attempt to get the user's tenant from his e-mail address. Is it possible to do so in any way using the common endpoint?
• Yes, you can get the user’s tenant name from the email address it uses to sign in with the ‘/common’ endpoint. Since, you are using a multi-tenant daemon application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Instead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: -
' https://login.microsoftonline.com/common '
• When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, therefore, discovers which tenant the user is from. The /common endpoint works with all the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation. The sign-in response to the application then contains a token representing the user. The issuer value in the token tells an application what tenant the user is from. When a response returns from the ‘/common’ endpoint, the issuer value in the token corresponds to the user’s tenant.
• The ‘/common’ endpoint is not a tenant and is not an issuer, it’s just a multiplexer. When using ‘/common’, the logic in your application to validate tokens needs to be updated to take this into account. Also, please take note that you cannot query the ‘/common’ endpoint and retrieve the user’s tenant name from its email address as it is passed as a credential grant claim to the Azure AD through the authentication protocols, however the redirection to the Azure AD platform is possible through the ‘/common’ endpoint only when the user logs in to the daemon app web api and the redirection is done internally by identifying the tenant name from the email address of the user.
Please refer this document for more information.
"Once the admin has consented to my daemon app he is redirected back to my website"
The redirect URL must have tenantId in it. 'tenant' is appended as a query parameter to the redirect URL once admin consent permissions.
When I log into Azure AD B2C I don't get the preferred_username claim included id_token. Is there a way to configure this from the Azure portal? Pretty sure I would get this claim in regular Azure AD OIDC implicit flow.
I've tried looking at custom claims but it seems like this should be a built-in claim that gets included or mapped to some attribute.
This is a known issue with B2C and the MSAL libraries.
From the MSAL .NET wiki: B2C does not return a value in the IdToken for the preferred_username because of limitations with the social accounts and external identity providers (IdPs). Azure AD returns a value for preferred_username because it knows who the user is, but for B2C, because the user can sign in with a local account, Facebook, Google, GitHub, etc...there is not a consistent value for B2C to use for preferred_username. To unblock MSAL from rolling out cache compatibility with ADAL, we decided to use "Missing from the token response" on our end when dealing with the B2C accounts when the IdToken returns nothing for preferred_username. MSAL must return a value for preferred_username to maintain cache compatibility across libraries.
If you want to display a value in the UI, you should be able to use the login hint to pass in a username to pre-fill the sign-in UI. As noted in this MSAL .NET issue.
This is a known issue with Azure AD B2C.
This is because Azure AD B2C does not return a value in the IdToken
for the preferred_username because of limitations with the social
accounts and external identity providers (IdPs).Azure AD returns a
value for preferred_username because it knows who the user is, but for
Azure AD B2C, because the user can sign in with a local account,
Facebook, Google, GitHub, etc. there is not a consistent value for
Azure AD B2C to use for preferred_username.
Here is the Workarounds.
Sign-in with Microsoft identity provider fails, works with others
I have an Azure AD B2C tenant with a SingIn and SignUp policy that I hope to use
for user management with an Angular2 SPA.
The policy is configured for three identity providers:
Google
Microsoft
Email Signup
When I use the Run Now button in the Azure portal to run this policy, I get the default Sign In dialog, and I can sign in with either Google or Email signin. (By that I mean I get re-directed to my app's redirect page as I expect.) However, when I try to sign in using the Microsoft
provider, I end up at an error page with the following address:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.&state=StateProperties%3deyJTSUQiOiJ4LW1zLWNwaW0tcmM6NDcyMmQyNjItOTk1Yi00YTJlLWFmNWUtODkwNDgyODlhMzM0IiwiVElEIjoiM2Y2ZDVmNjAtMDdiNC00ZDA3LWEyZDItN2U3YWQwOWRhOGQ5In0
I see that the problem is related to an invalid redirect_uri. But I thought the redirect_uri was an application-level setting shared by ALL identity provders that I have configured. Why does my redirect_uri setting work for Google and Email signup, but not for Microsoft?
You have to configure your Microsoft application with the right redirect URL.
As stated in the documentation:
Enter https://login.microsoftonline.com/te/{tenant}/oauth2/authresp in the Redirect URIs field. Replace {tenant} with your tenant's name (for example, contosob2c.onmicrosoft.com).
Why you have to do this: (courtesy of Chris Padgett)
The redirect URI that is configured in the Azure AD B2C Portal represents the reply address for your client application. This is so Azure AD B2C can return an ID token to your client application. The redirect URI that is configured in the Application Registration Portal represents the reply address for your Azure AD B2C tenant. This is so the Microsoft Account identity provider can return a security token to your Azure AD B2C tenant.
So, your app is federating authentication to Azure AD B2C.
B2C then further federates to the Microsoft Account identity provider.
So when a user a logs in with a Microsoft account, they are sent back to B2C with a token, which B2C validates.
If all is okay, they are signed in to B2C, and sent back to your app.
So you see that from the point of view of the MSA identity provider, B2C is the client.
So the redirect URL there must point to B2C.
As the document stated, you should Enter https://login.microsoftonline.com/te/{tenant}/oauth2/authresp in the Redirect URIs field.
But I thought the redirect_uri was an application-level setting shared
by ALL identity provders that I have configured. Why does my
redirect_uri setting work for Google and Email signup, but not for
Microsoft?
You're right, the redirect_uri is an applicaiton-level sttings. It should be same in all IDPs redirect URIs. But this Redirec URI is set by Azure. NOT your applicaiton. It means that your can use other IDPs to login to your app with AAD B2C, NOT login to your applicaiton directly. So, the redirect_uris must be https://login.microsoftonline.com/te/{tenant}/oauth2/authresp, not the redirect_uri in your application itself.
URI doesn't equal URL. The redirect URI is just a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request. It's not redirect URL, Azure AD authentication endpoint https://login.microsoftonline.com/ use redirect URIs to check where it should be responsed. Aslo, it can be same as the URL as the endpoint. Here should be the same I guess.
Summary, you need use the unique redirect URI https://login.microsoftonline.com/te/{tenant}/oauth2/authrespfor all IDPs , not just Microsoft account.
Hope this helps!
I'm trying to configure Azure AD B2C to use Azure AD (org-owned) as an IDP using the instructions here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom. I believe I've completed all the steps but when trying log in using an AAD account (using the "Run now endpoint"), after entering the username and password I get the error
AADSTS50011: Reply address '' specified by the request is not a valid URL. Allowed schemes: 'http,https'
I understand in general what a reply address is, but I don't know where the (apparently empty) reply address is being found. I verified that the AAD App registration representing AAD B2C has a reply URL defined, and that the B2C Application representing the actual web app has a reply URL defined. I've also verified that the same B2C tenant allows login through another defined IDP (MSA accounts).
Any suggestions as to where to start looking?
thanks
Martin
The reply URL that you input when you register an app in your Azure AD tenant (not Azure AD B2C tenant) is case sensitive. Make sure everything is lowercase.
In my scenario I have the following architecture elements:
- SAML secured Portal (Domain A)
- User
- SAML secured API( Domain B, so different domain than the portal)
- an IdP
The user will login first to the portal, when not authenticated, the portal will redirect him to the identity provider to login. Once logged in to the IdP and hence to the Portal, the Portal will possess a SAML token identifying the user.
Now this portal will need to automatically call the API (present on another domain), and pass to it a SAML token identifying the user. Problem is that the portal only posses the token that has been provided to him, and hence my question:
How can I propagate the identity of the user through the invocation chain?
For instance, is it possible to share same token between different relying parties? If yes, what are the constraints that the issued token should respect to make sure it can be "shared" by different entities?
Many thanks in advance!
One way could be that the portal rather than calling the API directly, instead should redirect the user to the API.
This way the API will find the user doesn't have a valid session, will redirect to the IdP where the user is already authenticated. The IdP will then redirect back to the API with the SAML response for the API.
This will all be transparent to the user, who will just see the result from the API.