I am having troubles running a web activity to fetch the new refresh/access tokens from Quickbooks online.
From Postman I keep receiving an "invalid_grant" error, likely since the refresh token changes every 24 hrs (seems excessive to me). From ADF I am getting a "bad_request" error. Does anyone have an example of the Web Activity they used in ADF to capture this info?
If someone could provide an example of the URL, Body and Headers they are using that would be very helpful. Not sure if I am doing something wrong or if this needs to be opened up with the Intuit team. Its most likely because the RefreshToken we have stored in Key Vault is no longer valid, but I want to make sure my Web Activity is formatted correctly first.
I have tried hardcoding the clientId and client secrets using basic authentication to the following url https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer in order to obtain the new tokens
I reproduce the same in my environment using web Activity and generated a bearer Token in Azure data factory.
Use Your User id and Password inside Body
output:
Alternative approach refer this SO thread.
Related
I'm using the auth endpoint https://login.microsoftonline.com/tenant-id/oauth2/v2.0/token programmatically (Nodejs) for getting back a token that will be used against my API. I have everything properly configured to send the request using a "Client secret" I setup on the Azure Portal - App registration service.
This issues a valid token that I can later check with the help of the Passport azure AD npm library. However I've been looking for a way of somehow adding more metadata to that token (i.e. a custom user name) so that when it gets validated and parsed by my server upon future requests I can extract this information.
When issuing tokens using a frontend application library (like msal) I have access to some of the user's information on the token (like its oid and email address). I'd like to be able to "extend" the token generated by the client secret to also contain a couple custom fields, which I can use after validating and parsing it.
Hopefully that's clear enough. I'm lost on how to achieve this. Thanks
It is a common requirement for APIs to authorize based on claims stored in the business data, eg roles or other custom data.
OPTION 1
Ideally the authorization server can reach out at the time of token issuance to an API or database to include the custom claims. This is not always supported though.
OPTION 2
Another option is for the API to process the incoming access token into a ClaimsPrincipal and to include custom values at that point. For an example see this code of mine.
PRIVACY
When adding more claims, you should also be careful about revealing sensitive data in JWTs returned to internet clients. Eg if you include names and emails, they are easily readable, and this can sometimes be a security concern.
Problem: I'm trying to use Postman to get an valid Azure AD access token that I can then use to pass on a request to an Azure Function protected by Azure Active Directory (Easy Auth).
I've read / viewed numerous explanations on how to do this. CGillum's entire blog for example. Some of the best ones (that don't quite work for me) are:
https://blogs.msdn.microsoft.com/devkeydet/2016/03/22/using-postman-with-azure-ad/
https://youtu.be/ujzrq8Fg9Gc
Even a similar question that I posted: Authentication for Azure Functions
I've verified that my ClientID, secret, and callback are all correct. I've ensured I have (what I think are) the correct permissions to the app I registered in my directory. I've got back a valid Bearer tokens in both of the first two examples above. No matter what though, when I pass this token back in the Authorization header I get a message that states "You do not have permission to view this directory or page."
My hope at this point is that someone reading this will point out the obvious thing that I missed.
Thanks in advance
We could use the following way to get the easy auth token easily.
1.Vist the following url from browser and input your creditial.
https://{yourfunctionAppName}.azurewebsites.net/.auth/login/aad
2.After that we could get the easy auth token after decode the url.
3.Test it with Postman
I'm creating a node.js application that will update playlists (owned by an account in which I have credentials) daily. According to the Spotify documentation, to add tracks to a playlist (https://developer.spotify.com/web-api/add-tracks-to-playlist/), authorization must be supplied using oauth2.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
I've been looking at the spotify web api node module (https://github.com/thelinmichael/spotify-web-api-node), oauth.io, and the spotify api.
Any ideas would be appreciated! There is only one account that will have to be authenticated, so it could be hard-coded at least for now.
You've picked the correct authorization flow - Authorization Code, since you need an access token that's connected to the user who owns the playlists you're updating. This of course also gives you the ability to refresh the token whenever you need to. (The expiration time is one hour, but you don't need to refresh the access token until your application actually needs to use it.)
As a sidenote, the Client Credentials flow is meant for server to server communication that doesn't require a user's permission, e.g. to search, read a playlist, or retrieve new releases. The Implicit Grant flow is meant to be used in frontends, and doesn't allow you to refresh the token.
I'm struggling to find a way to do this completely server side with no redirects/etc. It seems like if I can get a refresh token, I can just use that?
Once you have the refresh token you can continue to use it to retrieve new access tokens, which can be done without any user interaction. You need to do some preparation work to retrieve the refresh token though.
Following the steps describing the Authorization Code flow, you first need to direct the playlist's owner to a URL on Spotify's account server.
The documentation contains the following example URL:
GET https://accounts.spotify.com/authorize/?client_id=5fe01282e44241328a84e7c5cc169165&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback&scope=user-read-private%20user-read-email&state=34fFs29kd09
Simply replace the client_id and redirect_uri with your application's information. Also modify the scope parameter to match the scopes you need, which from my understanding of your use case is playlist-read-private,playlist-modify-private,playlist-read-collaborative since you want to be able to read and modify all of the user's playlists. Supplying state is not required.
Using spotify-web-api-node you can generate this URL using the createAuthorizeURL method, but since you're only doing this once it's unnecessary to write code for it.
Instead, simply open the URL in your browser.
If done successfully, you'll be taken through a little login dance where your application asks for your permission to read and modify your playlists. When this is completed, Spotify's account service will redirect the browser to your redirect_uri URL with a code query parameter included as described in step 3 in the Authorization Guide.
However, since you're only doing this once, it would be enough to start a webserver on your own machine, set your application's redirect_uri to your localhost, and complete the login flow. Have a look at web-api-auth-examples for a ready-made node.js application that fires up an express server and reads the authorization code.
Once you've got the code, you can trade it for an access token using cURL as it's done in step #4 in the Authorization Guide, or use the code in the web-api-auth-examples repository.
Finally, with the tokens retrieved (step #5), you can start to use the Web API with the access token, and get a new one when it expires using the request in step #7.
spotify-web-api-node has a helper method to refresh the token. Search the main documentation for the refreshAccessToken method.
This use case is slightly mentioned in the FAQ section of the Authorization Guide.
As you said, you need to obtain a refresh token using the authorization code flow. For that you will need to carry out the OAuth process using your user account, the client_id of the app you have registered, and the scopes you need (it will vary depending on whether the playlist is private or public). Then, take the refresh token you have obtained and the client secret key of your app, and you can obtain access tokens without the need of the login form.
This related StackOverflow question might help too Spotify automated playlist management with PHP back-end and rate limits
I am using Azure Active Directory and ADAL to interact with Exchange EWS of Office 365 with OAuth.
I know you can use authContext.AcquireToken() and It will manage all oauth for you. It will save, use, and refresh, tokens for you and also prompt to the user credentials when is required. The issue in my case is that I need the interaction in an Azure background web job so It wont be able to ask for the user credentials.
What I tried was getting the authorization code making the user visit the url from GetAuthorizationRequestURL(). Then getting a Token using AcquireTokenByAuthorizationCode() and saving the Refresh Token in the database. So when the background Job needs to connect to EWS it can use the Refresh Token (saved in the Db) using AcquireTokenByRefreshToken().
This approach works but I dont know how you can get a new Refresh Token when it expires after 14 days.
Any idea of how can I renew the refresh token or a better approach for using ADAL in a Background Job?
Thanks and regards!!
Here there's an idea. Create a simple console or win form app that requests your token. In that app, use a custom cache that saves tokens in a portable store (like an encrypted file, see https://github.com/AzureADSamples/NativeClient-DotNet). Run the app once to seed the cache. Then take that cache and deploy it together with your web job. Now for 90 days or so you'll be fine.
Another alternative is to use username/password flows but that's rarely a good idea and it entails many important limitations.
I have an OData feed that I want to consume using Excel/PowerPivot. The feed is protected using OAuth 2 (Windows Azure Active Directory is the auth server). The advanced tab on the PowerPivot table import wizard has some UI that allows you to specify OAuth and lets you put in an authorization token (I'm assuming this is an access token, but I could be wrong):
However, when I do test connection I get an error that tells me I have to put in a username and password if I'm not using Windows Authentication. This defeats the objective of OAuth 2, but as an experiment, I did put a username and password in. This time, when I test the connection I got an Unauthorized (401) error from the server.
Using fiddler to look at the request that was issued by the test connection I can see that no Authorization header was included in the request, so obviously it was never going to work. I would have hoped/expected that the authorization token would be included as a Bearer token in the Authorization header. This is what my service requires.
I also tried putting in a refresh token and arefresh token URL but the result was the same. There is an option to use a Client Secret but I haven't tried this because that would not be secure (I think OAuth 2 only supports that for confidential clients, which Excel is not).
So, my question is: Has anyone been able to use this OAuth option to import data in to Excel or PowerPivot? If so, how do you do it?
Update: I realised my service was not responding with the correct WWW-Authenticate header values as specified here:
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#authn-header
So I changed the service code. Now I see the the correct WWW-Authenticate response header (scheme=Bearer, realm=my realm), but it makes no difference. I don't see any change in the requests issued by Excel.
Update: I also tried using the OAuth 1 version of the WW-Authenticate header (scheme=OAuth) but still nothing.
I registered this with Microsoft:
http://connect.microsoft.com/SQLServer/feedback/details/802179/unable-to-import-data-from-odata-feed-protected-by-oauth-2
It turns out that this is a bug in PowerPivot. The decision from Microsoft is that they will fix the problem in PowerQuery rather than PowerPivot. At the moment, PowerQuery has the same limitation as PowerPivot.