I am trying to access a SP site outside of my tenant using a guest account provided by the third-part company.
According to them, the access is given using Azure B2B (ExternalAzureAD).
I want to access the SP site using Power Automate to copy files to my tenant. It is a specific list, but not specific files.
I tried performing common HTTP SP Rest requests (the connector using the guest account) and HTTP using AAD, but I keep having "401 UNAUTHORIZED" as a response.
Any ideas on how to perform this call? I have very little room for requests with the third-part company, and a request to register an application user to generate a token for me is almost certain to be denied.
What could I try here?
Thanks!
Related
I have a query about how keycloak is supposed to be working with client without GUI access.
Basically I have:
A keycloak server configured with a realm, clients(Access type confidential) and Users
A server application with a GUI that also provide API, secure with keycloak (client, user, blablabla)
This is kind of working already as I am able to log on the GUI, have the redirect, etc..
Even accessing the APIs works well, when I have access to a GUI: I log on my UI, follow the redirect and get my UI to display the token. The the human (to differentiate the user from an application), can use the token in any API client.
In this context the user never sees the client secret, which is instinctively the right way. (note that I am very opened to people telling me my instinct is wrong!)
What I am NOT able to do so far is to find the way a server application (without GUI) can get a valid token?
The authorization_endpoint, as far as I understand it, requires both the client id and the client secret) to get a token, which I would rather avoid: I don't think giving my client secret to all my "customers" is the proper way to do it.
Alternatively I could create an API on my client that woudl ask for user credential and ask for the token in its behalf, but that would expose the clients credentials to my application, which is against the whole concept!
I tried setting my client Access type as public, but when I use the API call below I also get a error:
POST /auth/realms/realmname/protocol/openid-connect/tokenAPI
'grant_type=client_credentials'
'client_id=client_id'
'username=username'
'password=password'
{
"error": "unauthorized_client",
"error_description": "Public client not allowed to retrieve service account"
}
Would anyone know how this is supposed to be done ?
Thanks in advance.
Max
(...) A server application (without GUI) can get a valid token... typically using the Client Credentials flow.
But we would define in this case a dedicated Client for your server (client?) application to authenticate against. The returned token (not bound to a specific user) will serve for authorizations on allowed applications (i.e. your classic GUI or API clients).
So, basically you should (in very short):
define a specific confidential Client in your Keycloak
add the desired applications (or other Clients) to the Client Scope(s). Those you want to authorize transitively from this Client.
authenticate against this Client with Client Credentials flow (given the token endpoint, client id, credentials, scope)
ensure that you are authenticating through TLS and that parameters are included in request body (and not in headers - for enhanced privacy)
further harden security of your Client(s)
When you do not want anymore this particular server (client?) application to access your applications, you can change the corresponding "authentication" Client's secret/credentials or simply delete it.
"I don't think giving my client secret to all my "customers" is the proper way to do it."
You are right and the proposed method above strictly avoids that. Each customer would have its own credentials.
EDIT
(adding more details)
By performing as above, you would end up with the following scheme:
Flow Keycloak Server
C/S app. or Customer X <--- Client Creds ---> Auth. Client X
--- Access Token ---> Appl. Client <--> Appl. Server
C/S app. or Customer Y <--- Client Creds ---> Auth. Client Y
--- Access Token ---> Appl. Client <--> Appl. Server
Browser users <--- Standard ------> Appl. Client <--> Appl. Server
Note: this is not a detailed flow chart. Arrows mostly show relationships here.
Finally, please note that the terminology may differ a little here, but the proposed method is basically the same that Google uses. So you may aswell take some inpiration from there:
https://developers.google.com/identity/protocols/oauth2
I just had the same problem some weeks ago
In my case, I have a backend API and a frontend application that the users can use.
Eventually, I can't share the client_secret to the frontend application.
So here is my solution:
On keycloak, create a client (ex front_end_client) with grant type public
This client is going to be used by the frontend application to authenticate users using implicit flow (with PKCE will be more secure)
On keycloak, create a second client (On the same REALM as the first client) with grant type confidential, this client is going to be used by the backend API
Now, this is how it works:
Frontend app authenticate users and get the access token (Using the font_end_client)
The frontend app sends this token for every request to the backend
Backend app verify this token, and can retrieve permissions from it
Response status code does not indicate success: 401 (Unauthorized) When calling Azure Blockchain
I am getting above error when calling Azure Blockchain RESTApi and I have checked all the permissions and getting Access Token correctly but When I call to get the applications we are getting Above mentioned Error
The issue was fixed, by following the below steps:
1) Go to Azure Portal-> App Service -> [Your App Service]-Api
2) Go to Authentication/Authorization Blade
Allow App Service Authentication and choose Allow anonymous requests(no action) and choose Azure Active Directory as Authentication Providers
Click on Advanced -> Fill in the options as in the following image:
Client ID is the same as App ID in the AzureAD Application Registration
Client Secret is the same as API Key you generated from the Keys Section in the AzureAD Application Registration
Issuer URL is https://sts.windows.net/{AZUREADTENANTID} ß You can get the azuread tenant ID from the AzureAD Properties
Allowed Token Audiences should have the following value:
i. [https://%7bYOURBLOCKCHAINAPIURL-API.azurewebsites.net/.auth/login/aad/callback]
https://{YOURBLOCKCHAINAPIURL-API.azurewebsites.net/.auth/login/aad/callback
3) Go to Azure Active Directory
Now, go to Azure AD and Navigate to App Registrations and Click BlockChain API ß or the name you chose for your Azure AD App Registration when you configured blockchain the first time:
Click Settings and Click Reply URLs
Add the following URLs there:
Blockchain Workbench URL (it should be already there)
Blockchain API Base URL (the one that has -API in it)
Blockchain API Base URL with Callback (as indicated below, but use your own URL and add /.auth/login/aad/callback)
The getpostman.com/oauth2/callback URL will be used later to test the API using the Postman App (An App used to test APIs), please add it as is below
4) Save your settings and then go to the Manifest(Next to settings in the Blockchain API AzureAD App Properties)
Set the manifest entry oauth2allowimplicitflow to True
Save Configuration.
That’s it, now we need to test the API, you can download Postman to test the API, the configuration of Postman is a little bit long, I would prefer that you sign up free on this service: https://www.wintellectnow.com/Videos/Watch?videoId=blockchain-on-azure
Use Code: FREETRIAL to sign up – It will require a credit card but it won’t be charged, use any prepaid or postpaid card, but watching this video is highly recommended, specially at minute 53 as it explains how to use the API with Postman (Remember to disable the trial to prevent the card from being charged after 7 days 😊)
Here is a sample Token generated using the built in Auth Sample code that comes with Azure Blockchain Samples on Gethub (You can download this from here: https://github.com/Azure-Samples/blockchain/tree/master/blockchain-workbench/auth-samples/bearer-token-retrieval/static ), if you are going to test using it, you must add http://localhost to the Reply URLs above and you have to place it on your localhost IIS)
And here is a sample from Postman which shows how the token is added to the request header:
Here is the response before the authorization token:
Once the authorization token is available, here is the response that is generated once I call the API indicated in the GET Section in the image above:
Also, here is the response headers after a successful authorization:
To sum it up, the #blockchain API requires #OAuth2 authentication token, this token isn’t passed using Swagger UI or the application you built, you need to modify your application to authenticate to AAD OAuth2 to obtain a Token from AzureAD, then you need to use this generated token in the request header to the API in order to call the API.
One additional tip, don’t select the default machine size while creating workbench, but choose better performance machines like: VM Size: Standard F2s_v2 (2 vcpus, 4 GB memory) ==> approx.. 50 USD per month .
Discussion on Microsoft tech community site
The original Post of the Author
We are currently experiencing an outage in South Central US
https://azure.microsoft.com/en-us/status/
Azure AD is also impacted.
You will want to monitor the Azure Status Page for further updates. Unfortunately we cannot do anything until the problem has been mitigated by engineering.
After the issue has been mitigated and if you are still seeing issues let us know.
I wish to obtain an access token without user interaction in order to automate REST API calls to Azure services (Compute, Network, etc.). In the documentation, several authentication scenarios are listed. The one that fits my use-case the most is "Daemon or Server Application to Web API".
I followed the instructions to request an access token : first I registered an App in my Azure Active Directory. Then I created a key (client_secret parameter) associated to the application ID (client_id parameter). I also obtained the App ID URI (resource parameter). I used all these parameters to create a POST request to the /token endpoint of my Azure AD. However I get the following error message:
{
"code":"InvalidAuthenticationTokenAudience",
"message":"The access token has been obtained from wrong audience or resource 'https://solutionsmosaixsoft.onmicrosoft.com/<APP_ID_URI>'. It should exactly match (including forward slash) with one of the allowed audiences 'https://management.core.windows.net/','https://management.azure.com/'."
}
What am I doing wrong? Am I setting the resource parameter to the wrong value?
The resource parameter tells your application where to get token(identifier of the resource for which the access token is being requested). If you want to get a token to call Azure Service Management API , you could set the resource as https://management.core.windows.net/ .
Edit:
If the APIs you want to call are Microsoft provided APIs , the resource is known ,for example :
Azure Service Management API:https://management.core.windows.net/
Microsoft Graph API :https://graph.microsoft.com/
If you want to call the API apps which your created , you can either use the Client ID or the App ID URI of the resource WebAPI (Find them in the configure tab of the Azure AD application in the Azure Management portal).
You could refer to below link for code samples :
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-code-samples
You need to make a POST request to the token endpoint.
The resource parameter must be the resource URI for the API that you want to access, not yours.
Azure AD Graph API: https://graph.windows.net/
Microsoft Graph API: https://graph.microsoft.com/
I am trying to read sharepoint user profiles using REST Api on userprofiles.peoplemanager Service.
We defined an application in azure AD, with "Sharepoint: read user profiles" permission for both application and on behalf of a user.
When i request the service on behalf of a user (for example getpropertiesfor(#v) with any user identifier passed as parameter), everything is working fine.
When i execute the exact same request on behalf of the application, i'm getting a HTTP 500 error.
Am i doing something wrong ?
What am i supposed to be allowed to execute on behalf of an application with the Azure AD permission "Sharepoint: read user profiles" ?
we've seen this SO question already and using the O365 REST API we have a working Oauth2 workflow that authenticates an O365 user and returns an access token. Our question is: Once we have an access token for a user, how can we discover the user's SharePoint servers (and associated endpoints) without knowing the authenticated user's O365 SharePoint server URLs ahead of time?
Our application uses Oauth2 workflows to access data on behalf of users from GitHub, DropBox, Google Docs and other services, and typically once user permission has been granted and we have an access token there is a straightforward way of querying/retrieving the resources for the user via the access token.
Once we have an access token, we're calling the O365 Discovery Services. If I'm reading the docs correctly, we should be getting back ServiceInfo entries on a request to the O365 /Services endpoint with an access token, like this:
https://contoso-my.sharepoint.com/personal/alexd_contoso_com
https://contoso-my.sharepoint.com
But at present we only get back O365 File and Contact ServiceInfo entries, even though in the Azure Portal when we created our app we specified Office 365 SharePoint Online Delegated Permission ('Read List').
If there are different O365 endpoints we should be hitting once we have an access token in order to discover a user's SharePoint servers, or if we're using the Discovery Services wrong, please provide a few pointers -- We want to solve this problem in a generic fashion based on Oauth2 workflow and don't want to prompt the user for things like O365 SharePoint Server URLs.
Lastly I'd mention that we're accessing this info in a purely RESTful fashion and we have no Windows-specific dependencies (in fact we're building things on the JVM) so a workable solution for us must not depend on Windows-only APIs or platforms.