I need help, I am new to PowerBI but I am know few stuff in Azure and C#. Anyways here is my current scenario: I am trying to get data from a REST API and show it as a report in my POWERBI unfortunately my REST API is AAD Protected so I need to provide an Access Code every time I tried to access my API. If you could point me out what should?
I usually use implicit flow to authenticate my user and for them to use my REST API but in this case is Implicit Flow still a possible solution? If not is storing Client ID and Secret safe to be store in PowerBI?
You can also use implicit flow with MSAL 1.X which is old version but it is not a recommended for the purpose of your apps security.
You need to handle the access code to automatically pass to the server and get the access token when using Auth code flow.
Technically For your scenario, you can also use client credentials flow which will not require a user credential involvement and there is no need to pass access code which is only part of auth code flow.
Related
I am building a React-based SPA that communicates with a spring-boot backend via a REST API. I need the user to be able to log into their Microsoft account on the browser client (the SPA) and I need the backend service (spring-boot app) to be able to query Microsoft's Graph API on behalf of that user.
After reading up on the Oauth2 flows, the authorization code flow (not the PKCE flow, just the regular authorization code flow) seems the most appropriate. The browser client could let the user log into their Microsoft account, retrieve an authorization code, and send the authorization code to our backend service via HTTP request. The backend service (which is trusted and can safely store a client secret) can then request an access token, make requests to the Graph API directly (meaning that the SPA would never need to make any requests to the Graph API), and silently refresh the token as needed.
However, I cannot see any examples of anyone using this flow to access Microsoft's Graph API.
Looking at Microsoft's documentation, it seems like they recommend using the on-behalf-of flow. But this flow requires the browser client to request an access token and then use that to communicate with the backend service (which in turn can communicate with the Graph API). It doesn't make sense to me why the access token cannot be requested on the backend using a client secret. Wouldn't this be a more secure and preferred method than having the client retrieve the access token, as is done in the on-behalf-of flow?
The Oauth2.0 site, recommends that SPAs should either use the authorization code with PKE or the implicit flow, but I do not see an option to use the standard authentication code flow for SPAs. Should I take this as an indication that SPAs should not be using the standard authorization code flow as I described earlier?
Despite not finding a clear-cut example of the standard authorization code flow in Microsoft's documentation for a react frontend + java backend, I tried to go about doing this myself. However, using the #microsoft/mgt-react and #microsoft/mgt-element libraries to do this are not straight forward. For example, the #microsoft/mgt-element notion of a Provider supports a call to retrieve an access token, but doesn't clearly expose the authorization code. If I wanted to do the authorization code flow described earlier, it seems like I would need to use raw HTTP requests, which I know is not a recommended way of accomplishing this.
Summarizing my questions:
What OAuth2.0 flow should I be using: 1) authorization code (access token is retrieved by backend service using client secret), 2)
authorization code with PKE (access token is retrieved by client), or
3) on-behalf-of flow (access token is retrieved by client, seems to be an extension of PKE flow)?
If using the on-behalf-of flow, does the SPA just include the access token in the header (marked as 'bearer') and the backend service just
includes that same header to query the Graph API, or does the backend
service need to request another token before querying the Graph API?
Agree with #ch4mp to call graph api directly in SPA if it's allowed. If not, then I recommend you using on-behalf-flow or client credential flow based on your requirement.
Let's come back to your requirement -- call ms graph api in a springboot api project. First, let's see one of the graph api getting user api. You can see permission types here: Delegated which means call graph api on behalf of the user, Application which means calling api on behalf of the application(your spingboot api project) itself. If you want to call api behalf of the user, then you have to use on-behalf-of flow. This is because the api project which will be considered as a daemon application, so the project itself doesn't have a UI page to let users enter username/password to sign in and get authenticated.
You can certainly use ROPC flow which have to pass the username/password to api but I really think it unsafe, so I don't recommend.
If it's not necessary for you to call graph api on behalf of user, you can certainly take client credential flow into consideration. But pls note here, application type api permission is a "large" api permission which always have name like User.ReadWrite.All, Mail.ReadWrite.All and it always means the application can not only query user information but also be able to modify user information.
If you want to use on-behalf-flow, then you may review this answer and it explained the whole progress...
I would use authorization-code flow (with PKCE) to get an access-token and then refresh-token flow to "maintain" this token, both from client.
Authorizing the request to your resource-server with this token only makes sense if Microsoft authorization-server is your main authorization-server. Otherwise (user also logged in with an authorization-server of your own or not using OAuth2 betwean React and backend), you can still send Microsoft access-token in request body.
In any case, when issuing requests in the name of the user from the backend, do as you suggest: just set the access-token sent by the client as Bearer Authorization header (token is retrieved either from Spring security context or request body). Backend fetches a new access-token (using client-credentials flow) when issuing requests in its own name (without the context of a user).
Side note: have you considered calling Microsoft API directly from React client? If you don't have to store the result of that call on your resource-server (i.e. call graph API to display data and store only what user selected from that data), that would save quite some latency on the client and costs (network and CPU) on the backend.
I am thinking of using IdentityServer4 for a new project. I am new to this and have done some reading and seen some of the demo clients in action.
Most of the clients in the samples allow login as a User and issue a token.
Requirement
I have multiple applications and the are for example, MVC/SPA/Mobile etc. I wish to allow each application to be a client and call an API.
I need a setup where applications can call a protected API without a user being logged in. So the API is protected based on scopes.
I know I can use client_credentials flow to get access_token and call my API. Which is fine for apps like the MVC as the secret will never be exposed.
I read that this flow is not recommended for mobile/SPA apps and to use Authorization Code flow, but I can't seem to get a token without it asking to login as a User.
Question
What other flow can I use to get only access_token without logging in the user and keeping my app secure?
Or, should I just use client_credential flow in my mobile apps and SPA's?
I am having difficulty understanding Hybrid flow with mobile application. I am using code id_token Hybrid flow provided by Identity Server 4 in .Net.
Here is my scenario.
All mobile request will go to backend server and backend server will forward request to different APIs on user behalf.
When user first time login
He will be redirected to identity server
A mobile web view will be opened
User will sign in using credentials
identity server will send Id Token and Access Code to Back end
Server
Back end Server will swap Access code for Id Token and Access Token
What token will be returned to mobile application to provide that user is valid. And is it responsibility of Back end server to get new access token without prompting user to re login until user sign out?
Is there any step wrong in above scenario ?
For mobile clients its recommended to use Authorisation code flow along with PKCE. Please read through these two answers to grasp some idea why its suggested Link-1 & Link-2.
Also, RFC8252 provide some best practices application for Native Apps (mobile clients are native apps.!). In that, it recommend not to use web-views.
here is a quote from RFC8252-overview
Previously, it was common for native apps to use embedded user-agents
(commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app
By using web-view, you loose the true essence of OAuth 2.0. You client app get the ability to grasp end user credentials. So use the browser instead of web-view. (Please read more about embedded users agents from this link)
In your architecture, you could enable all of these, PKCE, Authorization code flow and usage of browser instead of web-view. But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture.
But if you can make your mobile application to complete whole flow, you avoid that complexity. Once tokens are received, you may create a connection between backed server by validating tokens. Also, when tokens expire, mobile app will use refresh token to obtain new tokens.
I have an API locked down by Azure B2C. Everything is configured correctly for my client app that consume this API. My question relates to the integration tests that accompany the API. While it's pretty obvious that authentication triggers a UI to sign in, how would one go about requesting a token for tests cases that require authentication without popping a UI up?
Right now I have to have a utility that allows me to grab an access token (by popping up a UI) and then using that in my test project. Ultimately it expires so all the tests fail. This makes sense but I'm wondering if anyone has come up with a way to automate the process of acquiring tokens using this library so that the test cases can acquire them without popping up a UI. Screen scraper?
It looks like you want the Resource Owner Password Grant Flow. B2C does not officially support this, but Azure Active Directory does.
Read these:
Can I use "Resource Owner Password Grant" flow with Azure AD B2C
https://blogs.msdn.microsoft.com/wushuai/2016/09/25/resource-owner-password-credentials-grant-in-azure-ad-oauth/
Note that in the scenarios where B2C is simply acting like AAD (local accounts), you can use this flow. But for other social identity providers like Facebook and Google, you cannot use this flow.
I like your original method which is to generate an access token outside the app, and paste it in. I recommend adding to that the Refresh Token you got, and code to acquire a new token using an existing refresh token. Something like this.
Let me know if this helps.
We have a SharePoint publishing site with anonymous access hosted on internet. As per the latest requirements, we need to implement user login (AzureAD, Microsoft personal and work accounts, and more) for some pages within the portal.
There are two approaches we have come up with:
Using msal.js file. Implementing login of user at client side itself and calling Partner Center Web API with user token to check the validity of the user plus performing required operations.
Create a Web API with with Microsoft.Owin.Security.OpenIdConnect nuget package at Web API end to implement login and also use it for doing out required operation of retrieving and modifying data from the backend.
Which approach may work best in our scenario?
Is there any other way to achieve this?
The difference between these two approaches is that they are using the different flows to integrate with the identity data provider.
The second approach that using the server-side code is using the authorization code grant flow which is a stand flow to interact with identity data provider.
The first approach that using the msal.js is using the implicit flow. is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
More detail the flows using the OAuth 2.0 are defined in the OAuth 2.0 Authorization Framework.