I have an Azure app named myApp. This app is a website on which you have to sign in with your Microsoft account.
I created a scope in this app named myscope.
What I want to do is make a web request (in powershell) to this website.
I managed to do it with the method here by "manually" getting the code first and then the token and finally calling
Invoke-RestMethod -Uri "myurl" -Headers #{"authorization" = "Bearer $token"}
What I want to do now is exactly the same thing but in a fully non-interactive way. I mean without the need to log in manually. It can be with credentials, client secret or other ideas ...
Could someone explain to me the steps to do this?
Thanks !
This feels like you may need to look at the architecture, since you have 2 clients that need to get data.
GETTING AN ACCESS TOKEN (AUTHENTICATING)
If this sounds right then it would involve first registering two different entries in Azure AD:
Website client uses Authorization Code Flow to authenticate users via Azure and get tokens
Powershell client is not interactive so should probably use Client Credentials Flow
USING AN ACCESS TOKEN (DATA ACCESS)
The most standard setup would work like this:
Website client sends access token to a Web API
Powershell client sends access token to the same Web API
If the data access code is in the website itself then this may not work, since the web app is not designed to work for the Powershell client, and is likely to require a secure cookie that Powershell cannot provide.
FIRST STEPS
I would focus on the data the Powershell client needs and design how it should work if done properly. Can this be factored out into a small API as above?
If this is expensive then maybe a tactical solution could be used, such as a new website endpoint that accepts tokens and is only called from Powershell.
Related
I have a .Net 5 Web API hosted on Azure App Service.
The API has three Background services running as hosted services, which perform long running processes such as bulk emailing and SMSing, as well as other functionality that runs once a day on a timer.
I am thinking about moving out these hosted/background services into separate Azure Functions, which I would then call / trigger from my API via an HTTP request (except for the one that runs on a timer)
My concern is regarding authentication. How does that work with Azure Functions? Currently, my Web API is using Auth0 as the authentication server. So, when the user uses the front-end web app (Angular), he logs in (via Auth0's login form) and then the front-end retrieves an access/bearer token from AUth0, which it then includes in every call to the API (in an Authentication header).
Now, obviously I don't want just anyone to be able to call the Azure Functions - only my Web API should be able to do so. But how does that work? Does the API need to forward the access token it received from the front end to the Azure Function when calling it? Or is there something I need to set up in Azure Portal to tell it that my API must be allowed access to the Azure Function (and block any requests from any other origin)?
I've never used Azure Functions or even WebJobs before, so I'm a bit lost.
Thanks
When creating an HTTP-triggered Azure Function, by default it is set to have authorization level = Function, which means that any app trying to invoke that function via its URL needs to know the specific access key that is generated for that function upon creation.
In your example, your web API would store that function's invocation URL and access key in its configuration, and invoke your function with that key. Since the key remains entirely server-side on Azure, nothing else can access it, so it's completely secure.
Depending on your requirements, you can then also layer other types of authorization/authentication (e.g. bearer token) on top of the access key mechanism, or use those instead of access keys (by setting the function to allow anonymous access).
For maximum security, I would recommend using both the function access key as a first step to ensure that nobody except your apps can successfully invoke the function, and then passing along and authenticating the bearer token to ensure that the app trying to invoke that function is indeed permitted to do so.
Just be aware that Azure Functions is a slightly different beast to standard ASP.NET Core, particularly in regards to middleware which it doesn't really support yet, so you'll likely need to roll your own code for reading the bearer token from the incoming HTTP request's headers, and verifying that it's valid.
Reference: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=csharp#authorization-keys
For this requirement, you just need to enable "Authentication/Authorization" of your function app.
Follow the steps in the screenshot above and when you click the forth red box, choose "Express" tab and click "ok" at the bottom of the page without do anything. It will create an application in your Azure AD which has same name with your function app.
After that, when you request the function app url in browser, it will ask you to login.
For more details of the steps, you can refer to this document.
Hury's guidance is best - you want to avoid using API keys on your production functions and use this just for testing. Official guidance is here:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook-trigger?tabs=in-process%2Cfunctionsv2&pivots=programming-language-csharp#secure-an-http-endpoint-in-production
Configure your Functions for AuthorizationLevel.Anonymous, and require Authentication on your Function as Hury describes. This will not only require end users to authenticate, but supports System Assigned Managed Identity when your function is called from other App Services. Less keys to vault or configure means less to steal.
Depends on what you mean by authentication.
If you just want to secure your functions you can use the authorization level = function.
However, if you need authentication with login, and you need to know the user making the request, you have to use bearer token with OpenIDConnect server.
Always use stateless authentication regardless your method.
I have an Electron app that requires access to the users Google Drive and I want to implement the api functionality without having to expose the client secret. From my understanding, this is impossible to do in certain scenarios like mobile applications, but what is the proper way of going about this on a local app?
When trying to follow the web-app OAuth instructions from Google, it looks like you can't use this method on a local application. When trying to setup the OAuth process this way it doesn't even let you whitelist localhost as a domain to authenticate users on (which breaks the process since this is a local app running on Electron). Add on to that this paper that Google released and it also seems like you can't trick the auth process to think it's not running on localhost, and you also can't run Node.js in the browser (I'm using Electron so this is impossible to do).
I then tried following their Mobile and Desktop app workflow which seemed promising. The issue arises when you need to Exchange authorization code for refresh and access tokens. This again requires that you show your client secret in your main app. I then though of splitting this up and doing some of it locally and then having an auth server that held the client secret and exchanged the authorization code from the client and returned a refresh and access token. Looking at the diagram that Google provides for visualizing this process, it clearly shows that your app needs to do both parts of the authorization process so that idea was also out.
One application that I personally use and looked at was rclone and from the looks of it they just list their client ID and secret directly in their code. The client secret is encrypted, but if you follow the workflow it gets revealed with a key that is also just stored locally on the app. So it's plain text is obscured, but there is nothing preventing anyone from getting hold of the client secret by slightly modifying the code.
I should also mention this app is in a public repo on GitHub and will stay that way.
This is my first time using OAuth so I may be misunderstanding something, but I tried following the documentation as closely as I could and can't shake the feeling that I'm overlooking a piece of this process.
And if the only way to solve this problem is to expose both the client id and secret, is there any way this could lead to users data being compromised? Since the Google Drive API is free to use I don't really mind if others use some of my quota. I'm more worried about security.
For public clients like Desktop apps you're developing, you'll need to use the PKCE flow. You're right that Google's documentation seems off here - you shouldn't need to pass the client_secret as part of the authorization code exchange.
That's supported by the documentation here: https://www.oauth.com/oauth2-servers/pkce/authorization-code-exchange/
It's possible that Google requires the client_secret but it doesn't treat the parameter as a real "secret" for public clients, but rather an additional identifier that is not sensitive, and not sufficient on its own to do anything on behalf of your application. Section 8.5 of the specification reads:
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret. For this
reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT
RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret,
as this serves little value beyond client identification which is
already provided by the "client_id" request parameter.
Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public
client (as defined by Section 2.1 of OAuth 2.0 [RFC6749]), and not
accept the secret as proof of the client's identity. Without
additional measures, such clients are subject to client impersonation
(see Section 8.6).
You might also look into standalone OAuth service providers, like Xkit where I work. That would let you keep the secret confidential while still going through an OAuth flow.
I am trying to restrict access to my azure web app only to one of my web jobs.
Can I use IP Restrictions to achieve this.
To achieve this type of restriction, IP Based restriction will not be of use for the following reasons:
There might be other applications(owned by you, in case of standard above plans, or other customer apps in case of free/shared planes) that will be running on the same server and those also will have access to your web app.
There is no fixed outbound IP for your web job as it might be moving to different instances (in case you have multiple instances in your app)
A quick and easy solution for your original problem is:
Implement either BASIC Auth (username/pwd) or Bearer token Auth on your web app side.
From your web Job (in the Invoke-WebRequest) pass either the username/pwd or auth token based on whichever auth mode you choose.
Here are a few links that discuss implementing Basic Auth for Azure Web Apps and how to call such an app via PowerShell:
How to use the script (Invoke-WebRequest -Uri) to pass a parameter to your page
Use Invoke-WebRequest with a username and password for basic authentication on the GitHub API
How to use a C# code in the Web App to authenticate the request parameter
https://learn.microsoft.com/en-us/rest/api/datacatalog/authenticate-a-client-app
Since with basic authentication, credentials are passed in plaintext an can be easily decoded, we recommend that the web job calls the WebApp URL over SSL. Also, Basic Auth is one of the simplest authentication mechanisms, there are other more complex authentication schemes available too that you might want to explore.
I have a web api, using azure ad oauth authentication. I want my associates´ web sites to be able to use this api to display content on their public website. To clearify: No user should be needing consenting/grant anything and they are anonymous.
I have used this guide to set up my web api and this code ("Web Application to Web API"->WebApp-WebAPI-OAuth2-AppIdentity-DotNet-code) for my demo client.
The default scope/permission was assigned to client app in azure portal, like so
The actual problem I trying to solve is my different associates webpages should have different permissions. I was hoping to create different scopes and assign different associates client apps with different scopes and I could check if they for example has update_customer_x-scope.
All this "seems" to work ok. I get my authentication token and I am able to get content from the web api. BUT I dont get any scopes at all. Reading the first guide(web api) I see that you should be able to get the default scope by using the code:
if (ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/scope").Value == "user_impersonation")
{/*you have the default scope*/}
But I dont find anything here, and no scopes at all. Any clues?
This is the content of the JWT-token, as requested
The TodoListController.cs from WebApp-WebAPI-OAuth2-AppIdentity-DotNet just use the client credentials flow as astaykov commented for retrieving the access token without user interaction, at this time, if you decode your code via https://jwt.io/, you would not find the scp property.
For your requirement, you need to follow WebApp-WebAPI-OpenIDConnect-DotNet for calling a web API with the signed-in user's permissions.
I'm trying to connect to Sharepoint Online (Sharepoint 365?) content using OAuth2 and the REST API. I need to do this from Python as it is an addition to an existing application. I have already managed to connect the application to Google Drive using OAuth2 and REST, so I think I understand the fundamentals of using OAuth2.
I've tried a number of combinations of places to configure the client_id and client_secret and authenticate and receive access and refresh tokens.
So far I have been able to receive a refresh token and use it to obtain an access token; however, I'm unable to use the access token to access content on the Sharepoint 365 site.
For configuring the client_id and client_secret I associated my Sharepoint site with AAD using the Azure Management Portal. Then I added an application to the Sharepoint AD entry with the client_id and client_secret. In Sharepoint I used appregnew.aspx to register the client_id and verified the application appears in appprincipals.aspx.
I call the authentication service using:
.../login.windows.net/common/oauth2/authorize?api-version=1.0&response_type=code&client_id=&redirect_uri=&resource=Microsoft.Sharepoint
and am able to authenticate, receive a code, call back to
.../login.windows.net/common/oauth2/token with the code and receive access and refresh tokens.
I serialized those tokens and from a separate process call
.../login.windows.net/common/oauth2/token with the refresh_token, client_id, client_secret, and grant_type=refresh_token and receive a new access token.
Finally I call in to Sharepoint service endpoint
-my.sharepoint.com/personal//_api/web/files'
with the new access token and it fails telling me the resource Microsoft.Sharepoint is invalid (Invalid audience Uri 'Microsoft.SharePoint')
I've been spinning my wheels trying various permutations of where the client_id is configured and this is as far as I've gotten. Since all the documentation and examples seem to depend on using C# libraries such as TokenHelper I feel like I'm missing something key but simple and can't find the required information.
Has anyone connected to Sharepoint Online using Python, Ruby, Java, etc? If so:
Where should the client_id be configured?
What are the endpoints for obtaining the refresh and access tokens?
What is the appropriate audience uri or resource for which to request tokens?
Many thanks!
I've successfully connected to SharePoint Online using PHP. It looks to me like you're combining two different methods to do so.
Here is what I did:
Register my app in Azure AD on the Management Portal to get client_id, client_secret, redirectUri and the right permissions on Office 365 for sites.
Call the authorization endpoint at https://login.microsoftonline.com/common/oauth2/authorize
Call the token service endpoint at https://login.microsoftonline.com/common/oauth2/token
Call the SharePoint REST endpoint with the access token.
The resource should be simply the URL of your SharePoint site.
The appregnew.aspx and appprincipals.aspx pages are used for apps for SharePoint but it doesn't look like you're building one.
I think you are trying to do OAuth from Sharepoint Online without creating an Add-In inside Sharepoint. This was the exact problem I was facing. I know this is an old question but my answer might be helpful to someone else coming here.
It is possible to do OAuth from any web-app. Here are the step by step instructions in my blog -
https://medium.com/#yash_agarwal2/performing-oauth-and-rest-calls-with-sharepoint-online-without-creating-an-add-in-677e15c8d6ab#.6pf4wp83b
High Level overview -
1) Get client id and secret by registering yourself here - https://sellerdashboard.microsoft.com/Registration
2) Get Access Token, Refresh Token by following steps here -
https://msdn.microsoft.com/en-us/library/office/jj687470.aspx
Im probably a bit late to the party, but to whoever stumbles into this one, you can have a look at how the SharePoint Oauth App Client lib does it.
You'll probably want to check the SPSite and SPAccessToken classes.
I know this is old by had to deal with similar problem and have 2.5 solutions.
This solution is specifically for the federated logins.
Simple hacky solutions works like a magic for files :)
On Windows 10 - the silliest solution:
First login to your sharepoint with Internet Exploer/Edge. Must be IE/Edge.
Then in Start-> Run dialog or any Windows Explorer address bar do this: \\<your_sharepoint_site.com>#SSL\rest\of_the\path. Note #SSL after host name.
Make sure to replace all the forward slashes with backslashes.
This makes sure that your login credentials are captured by the system.
Then navigate to "This PC", menu "Computer->Map Network Drive" and paste either that same path from above or your normal URL https://<your_sharepoint_site.com>/rest/of_the/path into Folder text field of Map Network Drive.
Now you have Sharepoint folder mapped as regular network drive X:\! Which allows you to treat is just as normal file system folder from any program or programming language.
This solution uses WebDav WebClient and by default you will hit a 50MB limit! Worry not follow these steps to release yourself from the shackles of the silly limit.
Simple Hacky.
Open your browsers and open the 'Developer Tools'.
Navigate to 'Network' tab of 'Developer Tools'
With Network tab open login to your sharepoint site.
Click on any of the requests and you shall see that every single Request Header has a Cookie with FedAuth=some_very_long_base64_encoded_xml_struct;rtFa=something_else_long.
Basically you need these two cookies FedAuth and rtFa.
Now with every GET POST (curl, wget etc) request to the Sharepoint just add a new header Cookie with the value FedAuth=<fedauth-cookie-value>;rtFa=<rtFa-cookie-value>.
Programmatic-hacky (example in python on windows), essentially #2 but cookie manipulation all done programmatically.
We shall steal the cookie directly from the kid... I mean from the Chrome browser.
Navigate to your Sharepoint With the chrome browser and perform all the necessary login actions.
Steal the cookie gist. Plagiarized from here.
Use the cookie gist.
REST of Sharepoint REST API wisdom here and ref here.
Finally open a beer enjoy your day.