authorization code grant flow but without browser - azure-active-directory

Have to implement an app that gets username/password of Azure AD user from command line and obtain an access token to query ms graph. The AD application is created and configured to require MFA - it is a must (username/password flow is not an option).
I can use authorization code grant flow but that involves to open a browser and provide the user credentials but I don't want open a form an fill the credentials, I want to provide them internally (obtained from the user as app params). let's suppose that I use this app after I have ssh to a server. User should authorize this login by an authorizer app (MFA).
Any suggestion? Thanks.

The only flow that allows you to take credentials is the ROPC flow, which does not support MFA.
Device code flow could be an option if this is a console app: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code.
This flow gives the user a code that they need to enter in a browser that they can open on any device.
To me this feels like the best option.

Related

Server side login for Active Directory B2C

I would like to communicate with the Active Directory B2C from my backend to manage users. This seems possible here:
https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0
However, I don't see how to get a login token (or cookies) for a user so the server can send it back to the front-end to have it logged-in. How is it possible to implement this scenario?
I have seen this link but it refer to OAuth.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-custom-policy
Thanks!
Azure B2C auth flow cannot generate an access token for Microsoft Graph.
You need to implement AAD auth flow by following Get access without a user or Get access on behalf of a user.

Programmatic (API calls) User Authentication using Azure AD B2C instead of login.microsoftoneline.com form

New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.

Graph API - Daemon app with User Consent

We want to create an API App(Main purpose is to contact our organizations Office 365 Graph endpoint and send email) in Azure.. however our frontend website doesn't use Azure AD for the user authentication.. however we want our backend APi to be able send email in one of the following ways
1) send email as any user
2) send email on behalf of a service account
we are trying to explore the possible options and based on the investigation done so far, this(option 1) can be done using admin_consent - Can someone help with the steps we need to follow to create such app and deploy.
additionally is there a way to create an API app without login screen being prompted during the execution of the API - while using user_consent?
Option 1
In order for an app/daemon to send email as any user, it must have the send mail as any user app permission.
Give that permission on the Microsoft Graph API to the app, then grant the permission by clicking the Grant Permissions button in the portal, or by going through the admin consent flow.
Your API can then authenticate with its client credentials and get an access token to send email.
The bad side of this approach should be obvious, the app gets rights to send emails as anyone in your org.
Option 2
You could alternatively create an account for the API, and then use the Resource Owner Password grant flow to authenticate. You would then give the delegated permission for sending email as the signed in user.
The bad side of this is the flow for authenticating. If the account's password expires, there is no way for you to reset it from there, you would have to intervene to fix the problem.
Consent
You cannot go through consent without the browser UI.

Azure Active Directory B2C user signup without redirect (non interactive)

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.

Verify AD or LDAP crendentials via REST API

Our requirement is simple. We have a web application that requires users to sign up for a new account in order to use the service.
We would like to offer users to login using their AD or LDAP credentials, provided that an AD/LDAP connector was already installed on the client premises.
Is there any service that does exactly that (providing connectors and a REST interface to programatically verify user credentials), and perform a one time API integration so that users will be presented with a login form on our web application www.mywebapp.com/login, they will then enter their AD/LDAP username and password, which we would verify against their user directory using OneLogin API
I went through the API documentation for OneLogin but i have not see any method for doing that, although i can see at https://www.onelogin.com/active-directory-integration that it is a feature of OneLogin
After users are synchronized to OneLogin (via the Active Directory Connector or the LDAP Connector, for instance), an authentication call over the REST API will tunnel the username/password down to the Directory being synched for validation -- this should satisfy your use case.
For example you can use a function like https://developers.onelogin.com/api-docs/1/users/create-session-login-token, or just make an LDAP query against the LDAP endpoint.
Take a look at this new(ish) API from OneLogin -
https://developers.onelogin.com/api-docs/1/users/create-session-login-token
Although it's designed for developers to build their own front-end on top of OneLogin, it can also be used to validate a user's credentials (if you get a session_token, you've successfully authenticated the user)
This should 'reach back' through OneLogin to validate the users against whatever directory is configured to handle auth.
This call has the added benefit of supporting 2nd factors if they are configured.

Resources