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.
Related
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
I have a small application which was performing single sign on for logged in Windows Users by implementing my own Credential Provider and intercepting the Logon process and grabbing hold of the credentials. However it appears that with Azure AD login in a non-Hybrid case, grabbing credentials alone may not be the right thing.
Going by the blogs, here and here on this subject, it appears to be the case that in the case of Azure Login, the WinLogon process follows an OAuth workflow talking to Azure AD, using the PRT obtained during AAD Join and obtains an Access Token.
Currently the only way that I could find to get hold of this token is to use WebAuthenticationCoreManager . However I am a background process and my way of getting notified during the Logon Process was using the Credential Provider. To use WebAuthenticationCoreManager API I need to be a Universal Windows App.
How can i implement Single Sign on for my Application, upon Windows Login by an Azure User on a Win10 AAD joined device, using the Access Token issued for the logged in Azure User ?
• Winlogon process cannot be intercepted in Windows 10 AAD joined device because when a user signs in a device joined with or registered with AAD, a PRT (Primary Refresh Token) is generated which is an opaque blob sent from Azure AD whose contents are not known to any client components. You cannot see what’s inside a PRT.
• Also, a PRT contains claims generally contained in any Azure AD refresh token along with the device ID and a session key where device ID is used to determine authorization for Conditional Access based on device state or compliance and session key acts as the proof of possession when a PRT is used to obtain tokens for other applications.
• Please find the below token issuance flow during sign in process which clearly shows that token issued by Azure AD is verified by the CloudAP or local security authority based on the device certificate or trusted authentication protocols wherein it is saved as cache.
• However, you can add your app as a generic app in Azure AD for the SSO to be configured and used with it.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications
https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
I am able to read other users email using microft.graph api. Need guidance as how to restrict mailbox access so that users can view its email alone.
I created an azure admin and added 3 users. I registered an app and granted Mail.ReadWrite api permission. I generated a token and was able to read others users email. Need guidance as how mailbox access can be restricted to specific user and particular user can access their own email
Need guidance as how to restrict the users from accessing other users email
Client credential allows the app to read all the information that it have access to without a user. It means that anyone who opens the app can see the information. See Get access without a user.
What you need is Get access on behalf of a user.
To get an access token, the user is redirected to the Microsoft identity platform /authorize endpoint. In the authorization code grant flow, after consent is obtained, Azure AD will return an authorization_code to your app that it can redeem at the Microsoft identity platform /token endpoint for an access token.
At last, use this access token to access the emails of the logged in user. You won't see other users' emails.
I was able to restrict my app to access specific user email by creating an application policy. This link helped me to achieve this https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access Now I am using client credential to generate app level token and access specific users email.
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 have an entirely client side web page that makes ajax calls to Microsft ASP.NET Core client REST services. Both this UI application and the web service are registered in Azure ActiveDirectory tenants. I have successfully used another ASP.NET Core app registered in the directory to do user authentication and then request a JWT token for the web service and authenticate against that. Nowhere is the ASP.NET Core Authentication code did I have to specify scopes anywhere. If I wanted to call the graph API, I requested a token for https://graph.windows.net and used that.
Looking at this sample, which I made work in my AD, requesting a token for 'user.read' seems to be necessary. However, other samples just use ['openid'] or ['openid', 'email']?
I know that user.read is the AzureAd pernmission to read my entire user profile with the graph api. Does that imply whatever openid and email gives me?
The openid and email scopes are used in Azure AD v2 applications to get access to different info. They are not needed in v1 applications.
Quoting from documentation:
If an app performs sign-in by using OpenID Connect, it must request the openid scope. The openid scope shows on the work account consent page as the "Sign you in" permission, and on the personal Microsoft account consent page as the "View your profile and connect to apps and services using your Microsoft account" permission. With this permission, an app can receive a unique identifier for the user in the form of the sub claim. It also gives the app access to the UserInfo endpoint.
And about the email scope:
The email scope can be used with the openid scope and any others. It gives the app access to the user's primary email address in the form of the email claim.
User.Read is a scope for the Microsoft Graph API. Actually the fully qualified form is https://graph.microsoft.com/User.Read. But MS Graph API is a special case :)