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.
Related
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
I am very new to Keycloak server and want to use it to protect my front-end app and the backend rest API which are also open over the internet. So far what I understand and did is to create 2 clients on Keycloack, 1 is for frontend which used Client Protocol(openid-connect) with access type(Public) and then in client side i am using adopter to redirect the users to Keycloak login page and authenticate and get token. Now for the backend(rest-apis), I have created a separate client which again use Client Protocol(openid-connect) but with access type(confidential) and in Authentication Flow: both Browser Flow and Direct Grant Flow are direct grant and after that i get client-id and client-secret to call Keycloak rest api.
Now i want that when user are authenticated from frontend and get the token and send in header request to my rest API, here i call some Keycloak rest api to verify this token by providing client_id and client_secret.
I am using following rest api from Keycloak to verify the token which i generated at frontend:
http://localhost:8120/auth/realms/evva_realm/protocol/openid-connect/token/introspect
but result is getting like that:
{
"active": false
}
It my be i am using some wrong api OR the whole archetecture to verify and protect my backend apis are not correct. Can someone help me to understand where is the problem?
#user565 I found this medium post that works for me. I believe that you can benefit from it as well.
It basically creates two clients, one for the backend, and another for the frontend. The catch is that they share the same roles by leveraging the client scope, roles, and composite roles features.
Hope it helps: https://medium.com/devops-dudes/secure-front-end-react-js-and-back-end-node-js-express-rest-api-with-keycloak-daf159f0a94e
I am unable to create an OpenID Connect identity token to send as bearer token for a cloud run request. From the apps script I cannot make a token using (ScriptApp.getIdentityToken()) which has an audience the Google front end will allow through. When I arrange for the script to send a token instead that I've made with gcloud print-identity-token--identical except for the audience--that invocation succeeds.
Note I believe this may the same issue as seen here: Securely calling a Google Cloud Function via a Google Apps Script.
Also google cloud authentication with bearer token via nodejs.
One workaround suggests restructuring the GCP/Apps Script projects. Others mostly use service accounts, and use service account keys. I believe it's possible using IAM and use of google auth for one to produce a usable SA identity token (short term service account credentials) but I can't demonstrate it.
I am working around this currently, but I'd like to understand the essential problem. I think it has something to do with the cloud run service's hosting project's Oauth consent screen, and the inability to add the associated web application client-id as a scope.
In the Cloud Run docs, there is a section about performing authenticated calls to Cloud Run from other services outside GCP. The process would be the following:
Self-sign a service account JWT with the target_audience claim set to the URL of the receiving service.
Exchange the self-signed JWT for a Google-signed ID token, which should have the aud claim set to the above URL.
Include the ID token in an Authorization: Bearer ID_TOKEN header in the request to the service.
Step 1 could be performed as described here while setting the aud claim to the URL of the receiving service. I believe ScriptApp.getIdentityToken() does not set the proper audience to the JWT
For step 2, I believe you should perform a POST request to https://oauth2.googleapis.com/token with the appropriate parameters grant_type and assertion. This is explained in the "Making the access token request" section here
The resulting token should be used in step 3
I just wrote an article on that topic and I provide an easy way based on the service account credential API. Let's have a look on it and we can discuss further if required.
I'm setting up a service which needs to authorize against an existing Gitlab as OAuth Provider.
The service is a SPA which gets served by a webpack dev server in dev mode and a nginx server in production mode.
I'm also setting up an external API which should handle the Database and make request to the given gitlab instance (for example pull repos).
My SPA is authorizing against the Gitlab OAuth with the implicit_grant flow and is getting an access token. Currently I pass the access_token after the redirect to my API backend and there I get the Gitlab userid and username via a request to the gitlab instance with the access_token. With these I generate a jwt and send it to the client (SPA) and save it there so I can authorize my API with this JWT.
How would I handle the initial access_token in my backend (cause I need the token to make gitlab calls)?
Currently I'm thinking about writing it to the user in the database and get the user everytime he makes a request (normal passport flow), so I also have the token. But what if the token gets invalid or expires?
Should I use an interceptor in the backend and if the token is invalid (gitlab would give me a 401) redirect the 401 to my client, let him get a new token and pass it back to the backend, generate a new JWT, send this again to the client and let him do the same request as original reuested(via interceptor, too)?
Or should I just redirect the 401 to my client, let him get a new token, let him post this token to for example /renewToken and save the token to the database and use the old JWT?
Hope someone can help me unserstand this flow.
The Credential Management API should be what your looking for on the client. That will retrieve the id and access tokens to that you can compare access tokens with your server/ap and then validate the id token.
Haven't seen a Git example but there are Google and Facebook examples.
You could let the user send the initial access token and your backend API will just act based on the initial access token. Seems to me that it is not necessary to produce another JWT token in this case.
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.