I'm trying to use the MSAL.js library to sign in Azure AD and Microsoft account users. Right now, I use acquireTokenPopup() which requires me to pass scopes for an API. I'd like to just sign in the user without getting access tokens.
Anyone know how I can do this?
MSAL.js provides login methods to sign in users. The loginRedirect() and loginPopup() methods take scopes as an optional parameter in case you want to request scopes ahead for user consent. But it does not require you to pass scopes or get tokens for an API.
You can read more about MSAL.js usage here.
Related
I want to authenticate a valid Azure Directory user from my application. So the output that I want is the user is valid or not?
I use this API https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token with following urlencoded body like client_id, scope, client_secret, username, password, grant_type the for the authentication but this API is working only when the user disabled their MFA, but I want to authenticate even the user has enabled MFA.
You have hit one of the limitations of the ROPC flow.
It is not possible to authenticate a user with MFA enabled with that flow.
The solution will be to change your application to use an interactive flow like Authorization Code flow.
This will require that your app forwards the user to Azure AD to sign in, and then your application gets access tokens in exchange.
Pros:
You don't need to handle passwords
All the security features of Azure AD can be used, including MFA
Cons:
Complexity will increase (libraries help here)
Docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
If you have a Javascript front-end app, you can use MSAL.js to handle the authentication.
Other OpenID Connect compatible libraries can also be used.
I have the following requirement:
create a user on AD B2C.
using the credentials of that user, I need to get access token and refresh token to access an existing api(REST SERVICE).
Active directory here is Azure AD.
I am new in oAuth and Azure. Please suggest me the steps and configuration to achieve this. (I do not want any user interaction to get access token and refresh token).
creating a user is clear to me. but if it requires any specific type of user or any required permissions, please suggest those.
To me, it sounds like your use case can be better realized with a service principal. If you don't need a user context but, consider using an SP instead. See:
Microsoft identity platform and the OAuth 2.0 client credentials flow
If for whatever reason you want to stick to non-interactive user login, you can use the Resource Owner Password Credentials flow. But be aware that:
Microsoft recommends you do not use the ROPC flow. In most scenarios,
more secure alternatives are available and recommended. This flow
requires a very high degree of trust in the application, and carries
risks which are not present in other flows. You should only use this
flow when other more secure flows can't be used.
I have a collection of static html files, I would like to share with clients signed into my Azure AD B2C.
What would be the best method of doing so?
Ideally, the solution could also read certain claims from the token and decide which html files the client is authorized to access.
My Azure AD B2C is configured in a way, where only legitimate customers can get accounts.
I would now want to grant them access to the documentation of the products they own.
These are provided in the Token as a string Array.
The best way I can think of to do this is to create a lightweight Azure App Service that can handle the authorization piece and control role-based access by directory for the static files. As stated by Hari Krishna, you're going to need some form of Javascript platform for retrieving an access token using the Auth code w/ PKCE flow. Once you have an access token, App Service can control access to your directory based on the user's role present on the token.
For your scenario the most supported scenario will be Auth code PKCE flow. Which is helps you to authenticate with the help of any JavaScript platform and no backend programming is required. Also, Make sure each page is authenticated since , this flow is designed for single page application.
I have a problem regarding the permission granted to my app by the user showing up as a scope in my JWT.
I want to allow the user to see a list of his tenants (Office 365) on my page. For this I need a token with the https://management.azure.com/user_impersonation scope. I added the permission to the Azure API Permissions. When the user first logs in he sees this:
From this screen I assume my setup works, since the user gets asked to grant my app permission for what I need (Access Azure Service Management as you). But when I paste the JWT on the JWT Debugger I don't see the scope user_impersonation among the scopes.
I get this:
I already tried to remove the app from the test-user's applications (in their Azure Portal) to get it to ask again for consent but it's still the same. Other test users have also the same result.
What I'd need is simply to see user_impersonation among the scopes. That would allow me to call the API endpoint that returns a list of my user's tenants.
You need to acquire the access token for the https://management.azure.com resource.
Or if using v2, request it for the https://management.azure.com/user_impersonation scope.
That looks like an MS Graph API token.
An access token is always only valid for one API, so you need to ask for a token for the Azure Management API.
It works now!
So, I tried to get scopes for both https://management.azure.com/ and https://graph.microsoft.com/ in one single token. As Juunas explained, you have to get a separate token for each API. But can ask consent for both at the same time though.
My flow is this now:
I log the user in while asking him to consent to some permissions (for both API's and on first login only)
I request a token in the background for the Graph API scopes
I request a second token for the Azure Management API scopes
I need to write a backend app to read & write one company emailbox.
I have registered Active Directory Application and granted Delegated permissions (read and write to user mailbox).
Question is how to get the token needed for authenticate the graph api calls(for example ListMessages).
From the document I coundn't find any working example for backend app aquiring token and make api calls.
There are two endpoint versions:
Azure AD and Azure AD v2.0 endpoints;
And two authentication method:
1. Get access on behalf of a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user
2. Get access without a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_service
What shoud I use ? Really confused.
Thanks all.
According to your description, I assume you want to get an access token without user login page.
Based on my test, we can get an access token that run as a background services or daemons.
It requires administrator to grant the access permission once, then user will not see login popup window anymore.
For more detail, we can refer to this official document.
Sounds like you are looking for Resource Owner Password Credentials grant flow.
However its usage is not recommended.
It does not work in these scenarios:
User has MFA
User password has expired
User is federated (MS account/Google/on-prem AD)
The only scenario that I can think of where this flow is okay is integration tests of APIs where you need to test scenarios where you call your API on behalf of a user.
Here is a better way to do what you want:
Require an application permission to access user emails and have the admin grant it. Now you can use client credentials grant flow to get a token anytime you need one.
Use delegated permissions, have the user sign in once with Authorization Code grant flow. Then exchange the code for an access token and a refresh token. Store at least the refresh token somewhere secure. Use refresh token whenever you need a new token.
The first approach is more reliable but requires broader permissions.
The second has tighter security (only users who have authorized access can have their email read), but has slightly less reliability.
Refresh tokens can be invalidated, in which case you'll need the user to login again.