I'm trying to use the Sharepoint REST API and am stuck at the Authentication Step.
My tenant will not allow the registration of an App because they do not have support for site-specific permissions yet, so I want to request a FedAuth Cookie at runtime.
I am stuck finding the correct parameters for what request to make, in order to generate this cookie.
When following through Developer Tools via the browser, there are about 8 requests passed back & forwards.
Is there an endpoint / series of endpoints where I can pass my username/password, and generate a FedAuth Cookie, using the Sharepoint REST API?
Thanks
Related
I am trying to make an API request against a Dynamics 365 API account using Postman. I have the following credentials but I do not know what headers to use to authenticate.
I have the following ...
Consumer Key
Consumer Secret
Redirect Uri
Authorize Redirect URL
HTTP Method = POST
Access Token Service Endpoint
What headers do I need to set in Postman to get access to the API?
I have read articles and seen some examples but they all have different data than I do. For example in the screen capture below there is a username and password in addition to a Consumer Key (client_id) and Consumer Secret (client_secret).
I do understand that I need to obtain a Bearer token first before making the API call. It is obtaining this token that is confusing me.
Simply follow this documentation to setup the Postman for Dynamics web API, even the ready-made clientid = 51f81489-12ee-4a9e-aaae-a2591f45987d will work for any CRM online instance for testing purpose. You can use your customer provided clientid as well.
url should be https://crmdev.crm.dynamics.com
authurl should be https://login.microsoftonline.com/common/oauth2/authorize?resource={{url}}
First create an environment in Postman:
Use OAuth 2.0 in Authorization tab, and Get New Access Token.
I am creating a new .Net Core Web API that is consumed by a new React client-side app. Both the client-side app and the Web API are on different hosts and protected by Auth0. I set up both the client-side app and the Web API in Auth0, and then I created a machine-to-machine app in Auth0 to be able to communicate with the Web API silently (without a user interface). The security flow works like this:
User tries to access client-side app.
User is re-directed to Auth0 to provide credentials.
Auth0 authenticates the credentials and returns user info (including user ID + access token) to client-side app.
Client-side app stores user info in local storage for future use until it expires.
Any calls to 3rd party APIs are routed through my own Web API, so 3rd party API keys are sitting in a safe place on the server, not on the client-side.
User accesses a page that requires a call to my Web API but we don't have an access token for my Web API yet.
Client-side app reads the ClientId & ClientSecret (hard-coded values) from .env file and makes a POST request to Auth0 to fetch an access token for my Web API (this is Auth0's recommended way of getting the access token for the Web API silently except they don't specify where the ClientId & ClientSecret would be stored).
Auth0 returns an access token for my Web API.
Client-side app stores the Web API access token in local storage for future use until it expires.
Client-side app invokes my Web API with newly acquired access token as the bearer token in the header.
Web API receives the access token, authenticates with Auth0 and fulfills the request.
All of the above is working for me but I am concerned about storing the Auth0 ClientSecret of my Web API in the client-side app. Although it is not visible on the screen or in a cookie anywhere, any capable user would be able to get at it by inspecting the network traffic.
Many people on the Internet seem to be fine with storing 3rd party API keys in .env files while others advise routing 3rd party API access through your own Web API ... and I am doing the latter. But I still need the Auth0 ClientSecret to get to my own Web API and I cannot figure out a better place way to get to it without storing them somewhere on the client-side.
One last-ditch solution I can think of is to not protect my Web API through Auth0 and instead every call from the client-side app to my Web API should include something unique (like the user ID from Auth0) that can be validated by the Web API. Thankfully, the user ID from Auth0 will be stored in our database when the user is set up initially, so this is actually possible.
Does Auth0 have any other way for me to get the Web API access token without providing the ClientSecret given that I already have the client-side app's access token? I am curious to know how others have secured both their client-side app and their Web API through Auth0.
You are correct, you should not include the client secret in your client-side app. Do not use a client credentials flow, instead use a auth code + PKCE or implicit flow.
With that being said, Auth0 should handle most of that if you are using a library or SDK.
You have two options for getting the token:
When requesting the initial access token and ID token add the Web API as an audience and request the related scopes.
Make a silent request using the checkSession function for Auth0.js or getTokenSilently for auth0-spa-js
Take a look at this:
https://auth0.com/docs/architecture-scenarios/spa-api/part-3
I have an external endpoint which is going to hit the Azure API gateway and that would route it to the backend API which is protected by IdentityServer4 authorization.
I am getting the access token if I hit it through the Postman client with the interactive UI from IdentityServer.
Is there a way I can get the access token required from the Azure API Management to validate against the IdentityServer4 and append it to the header in the request to the backend API?
Yes it is possible to achieve it through custom policy. You can ask your external API-Client/Consumer to paas in credentials in heaser, and then you write a policy inside inbound to can read those user credentials and do a API request (similar to your postman) and get the access token. You can then append the same token and let your request gets forwarded to backend API.
As per your problem statement, this should work. In case not, you might have to explain your scenario with more description/steps.
Here are some of the reference materials for you, I hope it helps.
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#SendRequest
https://learn.microsoft.com/en-us/azure/api-management/api-management-sample-send-request
Postman has a luxury of a human user seeing the UI and authorizing API access and IdentityServer4 to issue a token for Postman. There is no such luxury when call is being processed by APIM server, as you could send request for token to IdentityServer4, but who would be presented UI to authorize the action?
The only way is to provision some sort of secret to APIM (header, query, certificate) that would be recognized by IdentityServer4 to allow it issuing tokens for APIM. If such secred is available you could use send-request policy to make a call to IdentityServer4 and obtain required token.
Or make sure that every request to APIM has a token already.
I have an application with users/password (not developed by us) that calls a web service to inform us when a new user is created. This web service should enable us to create automatically a user through the google Directory API service to create an account on the Google Apps For Education.
How can I do that without using OAuth but using only login/password for the admin user of the Google Apps account ?
I know to update CSV file to create/update accounts in Google Apps but would need to create the accounts on Google without doing manual upload and batch.
Thanks for your answer.
The old ClientLogin authentication method for Google APIs is deprecated and is not supported by the Admin SDK Directory API.
You should use OAuth 2.0. Once you have the OAuth 2.0 refresh token for your script, you don't need to reauthenticate the user each time, just grab a new access token if the current one expires.
You may also be able to take advantage of existing applications that already perform the OAuth work for you like GAM.
I just did this exact same thing in a GAfE domain. I needed to create 60,000 accounts quickly, and have them placed in specific organizational units (schools). I'm now putting together a series on how to make sense out of Google Apps for Education using the API explorer and OAuth 2.0.
Basically, you'll need to forget passing user/pass credentials using the API. You'll need to create an OAuth 2.0 ID (web application), and enter a redirect URI (the callback page that will process the request after authorization has been granted). At this point, you'll need to compile a URL string with the following information:
Base URL for the authorization request
data scope
client ID
response type
redirect URI
See the example below:
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/admin.directory.user&client_id=your_client_ID_copied_and_pasted_from_the_API_console&response_type=code&redirect_uri=https://www.example.com/callback.php
Once authorization has been granted, you'll be passed a code in the URL that you'll need to exchange for an ACCESS TOKEN using a POST request to https:// accounts.google.com/o/oauth2/token. The response will include the access token that you can then use in your POST request to the directory.users.insert API.
I have a web service built with WebAPI that accepts JSON requests and responds accordingly. The core architecture is built but there isn't any authentication/authorization.
After a lot of googling and poking around sample projects, I'm not sure where to start. I've found a ton of material from 2008 and 2009 but not a whole lot of recent guides/workflows for WebAPI / single page apps. I think the workflow should be as follows:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
Let the user log in / register: How is this data encrypted/decrypted? Surely I can't be sending passwords over the wire... is this where SSL comes in?
Provide them with access to what they have rights to access: I think I got this - I can just authorize in the controllers on a per-request basis.
Any info would be awesome.
Basically you need a token based authentication or authorization.
If you are referring to the ASP.NET WebAPI, the following project will be a great place to start:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Even if you are not using ASP.NET WebAPI, the following video is a great introduction on how to provide authentication/authorization on RESTful web services:
http://vimeo.com/43603474
To answer some of your questions:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
You can use a cookie but I normally use the header in order to avoid common XSRF attacks. Cookies are automatically included whenever a http request is sent from the browser.
is this where SSL comes in?
Yes. If you are going to go ahead with the token based approach, you can use a separate server (Identity Server) to do the authentication for you.
JavaScript clients are unique. Do you have the Web API and the page serving up JavaScript in the same domain? If not, you have same origin policy restrictions. If you have the same Web application hosting the web pages and Web API, you can use forms Authn. In that case, you don't need to send the cookie containing the authentication ticket yourself from JavaScript. Browsers do that for you and that is the cause of XSRF problem. You have to be careful about JavaScript sending credentials that the end user is not supposed to know. If JavaScript knows something, any intelligent end user can get to that knowledge. OAuth 2.0 implicit grant could be a good choice. The end user enters the credentials (password) in the authorization server which issues an access token. JavaScript gets the token and presents it to the web API but it will never have access to the credentials.