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.
Related
We're working on moving some apps from Razor Pages to React, and we'd like to use Microsoft Identity Platform for authentication via MSAL.
Some of these apps are multi-tenant, and we want to be able to validate that a given tenant is set up and authorized when a user logs in. Today, we do that in .NET via the OnTokenValidated event by pulling the email domain or tenant ID from the token claims and comparing it to our app's list of authorized tenants in our databases.
In MSAL, I'm not entirely clear how to accomplish that. The MS docs say, "If you allow multi-tenant authentication, and you do not wish to allow all Microsoft account users to use your application, you must provide your own method of filtering the token issuers to only those tenants who are allowed to login" (in https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/multi-tenant.md#multi-tenant).
Where in the React login or token acquisition process can I inspect the claims in order to perform this filtering? How are others handling these kinds of checks with MSAL on a SPA front-end framework like React?
I want my application to be able to use an external user pool from my customers Azure AD, instead of them having to maually create every user in my application, when they already have them in Azure AD.
Initially, I though of using only OIDC for this as I can just create the user in my application upon the first login. But OIDC does not allow me to logout and deactivate the user in my application when they are deleted in Azure AD. This is an important requirement for my application.
To solve this, I think I could combine OIDC and SCIM:
Azure AD provisions the users to my application through SCIM endpoints. When deactivated, Azure notifies my application through the SCIM endpoints and I can delete their session and deactivate them in my application.
Login is handled with OIDC. When I have a valid OIDC token I create a session in my app. This way I don't have to manage passwords or multi factor authentication in my app.
Does it make sense to use SCIM and OIDC together?
Yes, it makes sense to use SCIM and OIDC together in the way that you describe.
It also has other advantages to "pre-provision" with SCIM: for example, when users want to address accounts other users that have not logged in yet. Adding such a user to a group would not work with "just-in-time account provisioning" since the account would not exist (yet).
I have a consumer facing application (call it consumer.com) whose user identities is managed via. Azure AD B2C. This consumer.com app has admin screens which is accessed by the internal staff whose identity is managed by Azure AD. To enable SSO experience for the internal staff the organizations Azure AD is registered as Custom Identity provider in B2C tenant. This allows the internal staff to use the corporate Azure AD credentials to login to the consumer.com application by clicking on the appropriate 'External identities' button. In this flow if the internal user has already authenticated to Office365 then clicking on the 'External identities' button will automatically authenticate user. I was wondering if the experience can be improved by cutting short the need for internal user to click on the button, perhaps the user session that exist in the browser can be used to bring in this experience. How to achieve this?
I am also looking for a solution where user will click on a link (Consumer app button) within one of Office365 apps which would then redirect to consumer.com application, of course the expectation here is to directly authenticate without needing to go through B2c login page. If this can be achieved, what information should the url link contain?
Use the domain hint parameter:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin#redirect-sign-in-to-a-social-provider
I have been doing some R&D on using the MicrosoftGraphAPI to fetch the skus subscribed by my organization.
I have created an app as described in the documentation. I did all the steps in the above link except 'Assign application to role'.
Using postman am able to get the oauth2 token by sending a post request using the link
https://login.microsoftonline.com/<mytenantid>/oauth2/token
with the client_id, client_secret, resource(https://graph.microsoft.com) and grant_type(client_credentials) parameters.
After this token is obtained I can fire a get request https://graph.microsoft.com/v1.0/subscribedSkus with the Authorization header set as Bearer {token} which will return the SKUs subscribed by my organization.
So far so good. :-)
Now the requirement is I need to fetch the subscribed SKUs by one of the client (let's say having the azure ad tenant id 'ABCDEFG') of my organization.
I can successfully do that by registering an app in the client's tenant 'ABCDEFG' with the same steps as above.
This approach is fine if my organization has say 1 or 2 clients.
However, if the client numbers are more than say 30 this approach of registering an application in each Azure AD instance is not feasible.
If the application that I registered in my organizations AAD was multi-tenant then how should it help me?
What will be the steps needed to obtain the access token for each tenant?
Can somebody assist with some detailed explanation?
Since you need application-level access, you would assign one of the Application permissions listed in the documentation for getting SKUs: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/subscribedsku_list.
Directory.Read.All, Directory.ReadWrite.All
In this case you should require the Read Directory Data (Directory.Read.All) application permission.
Then you mark your app as multi-tenanted.
Now then in order for another org to use your app, they will have to be on-boarded.
You will need some kind of page where their administrator can click a button/link to start using your app.
This should redirect the admin to:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=your-client-id&prompt=admin_consent&response_type=code+id_token&redirect_uri=url-where-to-send-user-back
Once they sign in, they will be presented with a consent screen, where they can approve the permissions that your app requires.
If and when they do that, they will be redirected back to your app (to the URL you specified) and you can use the Id token to know which Azure AD tenant registered.
During this process a service principal for your app is created in their tenant, and the required permission is granted to it.
This means you can then get an access token for their tenant from: (using the same credentials)
https://login.microsoftonline.com/their-tenant-id/oauth2/token
Remember that access tokens are specific to an Azure AD tenant, so you will have to get an access token for each tenant.
One thing I would like to point out is that you should instead try to use delegated permissions if possible.
The application permission given here gives quite large access to your app, and some admins might not use your service for that reason alone.
Delegated permissions are more complex to handle, but allow your app to act on behalf of a user instead of purely as itself.
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.