Our application allows users to authenticate via Azure Active Directory using OpenID Connect.
However, some organizations do not allow users to approve applications, and require administrators to approve the application first.
Right now, this means that if a user wants to connect using their work account, we have to first send them to Azure, where they then enter their password, and then are told that our application requires administrator approval. Not a great experience.
Ideally, I would like to give only users whose tenants allow them to approve new applications (or those that already have) the option of logging in via AAD. Is this possible to do through an API call?
Microsoft does not provide such an API for this purpose.
As a workaround, you can quickly check it using auth code flow: Request an authorization code.
Enter their password is necessary. Sign in to this url with customer's credential:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Then they can see if they need admin consent or not.
The essence is the same as the steps you described. But it can save a lot of time.
Related
we are using UIPath within our company for RPA. We tried setting up UIpath to send mail on behalf of other users. We followed this guide: https://docs.uipath.com/marketplace/docs/microsoft-office-365-setup
There are 2 odd things to this setup:
We HAVE to make the App Registration a "Public Client" in Azure. To my knowledge, normally this applies to frontend web applications where the app secret cannot be kept hidden. This is a backend process, so I think there is no reason of having to use a public client. Am I right in this statement? What are the downsides of having a public client? Anyone possessing the client_id can impersonate this app registration? (can act as this app registration and ask users for credentials and get a token on behalf of this app?)
I added some api permissions to the App Registration like mail.read, mail.send, etc. It stated that no "Admin consent required", but it didnt work. After I pressed the "admin consent" button it said that it granted those permissions and the configuration seemed to work. What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Some extra clarification about the public credentials:
-I register an application called App-X, which is set to public.
-Normally, without a public client, when I request a token, I need both the client_id and the client_secret. By using the client_secret, microsoft knows that I am indeed really the application App-X who is requesting this token on behalf of the user.
-Without using client_secret, anyone who knows the client_id, can request consent from a user and say "I am App-X and I am asking for permissions", while in fact they are not App-X (just some random someone who finds the client_id). After the user consented, because "he knows App-X and he trusts it", then the malicious user/app can also request a token from microsoft because he only needs a client_id.
1.This is a backend process, so I think there is no reason of having to
use a public client. Am I right in this statement? What are the
downsides of having a public client? Anyone possessing the client_id
can impersonate this app registration? (can act as this app
registration and ask users for credentials and get a token on behalf
of this app?)
It depends on your application type. "Public client" is usually used to configure mobile and desktop client applications. Since UIPath is a mobile application that monitors the RPA environment, for your application registration, you need to choose to use "Public Client" registration.
If you don’t want your application to be used by users of other organizations, you don’t need to register the application as a multi-tenant application when you register your application. If your application needs to be used by multiple organizations, you need to register the application as Multi-tenant application. In this case, in theory, all tenants can use this application. However, you can verify which tenant the logged-in user comes from when logging in, and you can prevent tenants that you do not want to log in from logging in. Please see:here.
2.What does this ADMIN CONSENT button do? If I add permissions to an App Registration, do I always have to press admin consent?
Each application registers permissions it requires. Some permissions can be granted by users, some other only by the administrator.
Let's suppose you have only permissions that can be consented by users. The first time they use the application, they'll be prompted (each user) to consent those permissions to the application. If in the same scenario you click on grant admin consent, it is the equivalent of accepting it for all users on the tenant.
Now let's suppose the application registers permissions that require admin consent, you have no choice but to click that button if you want the application to work and be able to request tokens.
For those permissions that require the administrator’s consent, you You can go to Azure portal>App registrations>API permissions>Admin consent required to view .
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
I would like an AAD app to act on behalf of a user, without requiring the user to login to authenticate himself. E.g., I would like an app to be able to send an email from a user's account on the user's behalf programmatically using Graph API, but based on an event, and without user sign in each time to authenticate. Is this something that is possible using AAD delegated permissions?
I cannot use the client credentials flow using application permissions, because my admin will not grant access to my app, so I am looking for a viable workaround.
Thanks in advance!
You will need the user to consent your app using his/her e-mail address. Or an admin consenting the app to use everyones e-mail address. No other way.
Check out this article which describes dealing with long term access to APIs without presence of the user. And this here, describing the offline_access scope.
But, without someone letting you use their e-mail, you cannot use it. Period.
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I am building a native iOS application and want to use AADB2C as identity provider where users login, signup, reset their passwords etc.
I cannot figure out a way to let users signup with AADB2C (or regular AAD for that matter) without redirecting them to a (customizable, but still) microsoft website. To be perfectly clear: I want to let customers create user accounts on AAD from a native iOS form without redirecting them to a website, preferably via REST request. (Like here under "Create consumer user accounts": https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet)
Can you create users from an iOS app?
Yes, using the Graph API as per the article you showed. You can only create local accounts at this time though.
However you need to be very careful about how you do it given that currently, the ability to create users requires Directory.ReadWrite.All permission, which also allows all other sorts of operations. You should NOT put the client ID and client secret for an app with these permissions in your iOS app. Rather, you would need to create a backend service that exposes an API for your iOS app to call for user creation.
However, more importantly, what you WON'T be able to do is SIGN IN the users without a redirect (which is what the B2C sign up policy does). In order to do this from your own UI without redirects, you would need Azure AD B2C to support Resource Owner Password Credentials Flow so that you can, after creating the user, use this flow to sign them in and get a token.
Note: You would also need to disable Email Verification so that you can leverage the user account right after user creation. You can set this in the Sign-up policy or Sign-up/Sign-in policy via Page UI customization > Local account sign-up page > Email Address > Require Verification > No
Lastly, as an FYI, there's a feature in the works in Azure AD B2C: Customer Owned Domains, which, paired up with UI customization, would allow you to have sign-up/sign-in pages that you can look like your own and have a URL of your own, with no trace of Microsoft for your end users to see.