i need to get Azure token in my app (C#) to perform Graph API operations on users, but without sign in all the time when app invoked (app must be full automate, working in timer job) so i have a question how to made process of token acquiring fully automate (without user)?
All that I found about this topic:
Get access without a user
But I failed to recreate it.
The OAuth2 flow you are describing is called the "Client Credentials Grant" and is in detail described here.
In short it is relevant in this case and works like this:
First, user interaction is not possible with a daemon application,
which requires the application to have its own identity. An example of
a daemon application is a batch job, or an operating system service
running in the background. This type of application requests an access
token by using its application identity and presenting its Application
ID, credential (password or certificate), and application ID URI to
Azure AD. After successful authentication, the daemon receives an
access token from Azure AD, which is then used to call the web API.
Have a look at this implementation to see how it is done in code.
Using OAuth On-Behalf-Of works exactly what you describe. Which On-Behalf-Of method, there is no user interaction to obtain the user's consent to access to the downstream API (e.g. Graph API). In other words, the user identity & permission is silently delegated in a full request chain. In a real-world corporate environment, your app would be normally authenticated by another identity provider (e.g. Active Directory) not Azure AD, which after then requests authorization to Azure AD OAuth endpoint.
When requesting access token, you must set its type is requested_token_use=on_behalf_of
Here is reference to POST to the endpoint https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-on-behalf-of
Here is the reference of SSO authentication with OAuth On-Behalf-Of https://learn.microsoft.com/en-us/outlook/add-ins/authenticate-a-user-with-an-sso-token
Related
I have a front end SPA (single page application) and back end api.
Each event in the SPA (like button click) invokes the respective api endpoint, and displays the result in the SPA.
I want to implement Azure AD based authentication so that only my Azure Tenant users are able to use the SPA/api.
Is the following flow correct approach to implementing such a feature:
User opens the SPA
User clicks on login button which opens Microsoft login popup
User enters Microsoft credentials in the popup, and if credentials are correct then user gets the JWT token
For every subsequent api request, the JWT token is placed in the bearer header
The endpoint validates the JWT token using Azure public key and rejects the request if token is missing or validation fails.
Is this flow correct and what is such a flow called?
There are several implementation steps that needs to be performed before you will have the flow that you have described:
User flow needs to be configured (Azure AD) - e.g. selfsignup allowed?
Backend and frontend applications needs to be registered (Azure AD)
Permissions and scopes needs to be added (Azure AD)
Backend API needs to be configured (e.g. API management) in order to validate the JWT token
I highly recommend to configure one of the Azure sample implementations end2end to get and idea of all the needed tasks: https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-authentication-sample-spa-app
The steps you outlined are correct.
An OAuth 2.0 "flow" outlines the steps to acquire a token from an Identity Provider (IdP). Since you are using a SPA, there are some restrictions on which flows you can use. A SPA can't act as a "Confidential Client" which is required for some flows. (Basically - the Client Secret required for the other flows would be visible in the browser network trace, so it's not "confidential".) The "Implicit Flow" used to be recommended for SPAs but it's less secure, so now the "Authorization code flow (with PKCE)" is recommended. Steps 2 & 3 in the question above are when you are executing the flow to acquire a token.
The authentication flow doesn't really address how you save and send the token to the API (#4 in the question), but the Microsoft Authentication Library (MSAL) helps with that - More information here - https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-overview
In Azure AD, you'll want 2 App Registrations - one for your SPA and one for your API. The API App Registration will need to "Expose an API" which really means to define a scope. Your SPA App Registration will need to Add an "API Permission" to the scope you defined from your API App Registration. (It will show up in My APIs.) This relationship is how #5 in the question is enforced.
Many of the steps for setting up authentication in Azure AD and Azure B2C are similar but Azure AD is designed for authenticating users that are part of your organization. Azure B2C allows you to build a set of users that aren't members of a particular Azure AD organization.
We would like to use Azure client credentials flow to do authentication for our service accounts. The thing is our service accounts are just regular users in Azure AD. They are not registered apps. The way our company sets up Azure makes it very heavy to register apps, so we would like to avoid it. So the question is, can we use client credentials flow for regular users in Azure? We need this as in our CI/CD we cannot popup a browser and let users do device-based authentication. We need the user to be able to authenticate in an automated way.
You can't use client credentials flow where an Azure AD user is involved in the authentication flow.
Micrsofot Documentation - client credentials flow
This type of grant is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user.
But you can use one of the following supported authentication flow where a user is involved;
Micrsofot Documentation - authorization code flow
Micrsofot Documentation - implicit grant flow
Micrsofot Documentation - device authorization grant flow
Device authorization grant flow might work in your case?
I am using an Azure ADB2C tenant to sign-up/in users with custom policies and rest api claims exchanges. This works fine.
Now I would like to start a service (daemon) that runs in a cloud environment for each user that signs-up with my service. This background service will access resources on other servers. Accessing these resources require a token and the service should only have access to the resources that the user has (i.e.: the access token used by the background service should also include the custom REST API claims). For the common users, this is taken care of by my REST API claims server, which enriches the token in such a way that it gives users' access only to the allowed resources.
I have found this page describing how to get access without a user. But this page assumes that the background service is a single instance that has access to all users' data that it needs. My background service is a 1-to-1 mapping to the signed up user.
Ideally this is how I see it working:
A new user signs up.
My REST API claims exchange gets called for this user.
Call Azure ADB2C to create a token for the background service. (Token should also contain my custom claims)
Start a new instance of the background service using the token created at step 3.
Return the custom claims for the new user.
This will happen for every new user, so every user in my system will have a corresponding background service running in the cloud.
Is this possible with Azure ADB2C? If yes, how?
The link you provide to get access without a user is only suitable for calling ms graph api and not for calling custom api.
If you are calling ms graph api, then you can indeed use the daemon-based client credential flow to obtain an access token (that is, without user involvement). This flow is usually used in Azure AD, but if it is used to call ms graph api, then it is also applicable to Azure AD B2C.
But if you are calling a custom api, then you must use a user login flow. Azure AD B2C obtains tokens in a different way from Azure AD. To use Azure AD B2C, you must first create a policy to enable users to sign up and sign in to your application.
I am trying to have two applications(app1 and app2) in Azure
AD B2C, which is configured for Web api and another application that is configured for mobile app.
I need my mobile app to talk to app1, get the access token, using the app1's application-id and scope. Then use the access token got from app1 to communicate with app2. I enabled SSO in tenant level in the policies but it still says "Authorization denied" for the access token provided.
How can I reuse the access token got from one application to be used in another application.
We have been trying to get through this limitation (or function as designed for security) of B2C AD from weeks.
However, Microsoft does not support it.
We did not want to display MS login page to mobile user on mobile login screen (UX gets compromised). But MS says there is no way possible to avoid it. See response from MS on support ticket.
For more information: Azure AD B2C: Requesting access tokens
You will also benefit reading authentication scenarios supported. We are after something similar to this what they call "Daemon or Server Application to Web API".
In this diagram, Server Application = to mobile application in our case. However you will notice that in this scenario it is assumed that the user is already authenticated (via interactive flow).
We tried to act smart, thinking we can write a Auth web API which mobile will hit to obtain token and then pass this token to our business logic API (secured by B2C AD). We obtained access and refresh token somehow, however the test web app (mobile app) when pass this access token to our business logic API, it fails to validate the token. B2C AD comes fighting for it. Our analysis is not yet complete.
However, I am certain what we are trying to accomplish is not supported in B2C AD.
Hope this helps (I would actually advise you to look for other solution). I will be happy if someone can suggest a way to solve this obvious business problem.
I have a native client (console app) from where I am trying to access a WebAPI. The API has been authenticated using Azure AAD. So, in order to acquire a token using the method AuthenticationContext.AcquireToken(), ClientCredentials are needed which in turn need the "client secret" that one is supposed to receive from Azure while registering the application to Azure AAD. Is there any other way for me to be able to retrieve the access token to access the WebAPI?
If you want to call the WebAPI on behalf of (or "as") the current user then you can use the Resource Owner Credentials flow. Otherwise, the client credential flow you described is the appropriate solution.
Note that your client app should be registered separately from your WebAPI in AAD.