Here is what I tried, with the following result:
ERROR Twitter Search 0:2
Execute failed: 401:Authentication credentials (https://dev.twitter.com/pages/auth) were
missing or incorrect. Ensure that you have set valid consumer key/secret, access
token/secret, and the system clock is in sync.
message - Invalid or expired token.
code - 89
Try regenerating the API keys and secrets. The Twitter API Connector node will "run" and show green lights even if the connection is not established. I have had this issue a number of times, going on the Twitter developer site and generating new tokens, entering them in KNIME and running your flow again will fix the issue (hopefully).
enter image description here
Related
I am setting up the DocuSign rest connector in power apps. I have other API's that working well this same way.
I want to get this setup to sweep completed files on a scheduled.
I started by going through this tutorial and tried the same setup. But when I try to test the connector I don't get prompted for credentials. We use SSO - so the window comes up and goes away without an error message.
https://www.docusign.com.au/blog/get-the-flow-sending-docusign-envelopes-microsoft-power-automate
I then tried to create a connection in in power automate Data/Connections and get an error message after entering my dev credentials. The clientid (integration key) and the secret match.
OAuth2 authorization flow failed for service 'Generic Oauth 2'. OAuth 2 sign in failed to exchange code for access token. Client ID and secret sent in form body.. Response status code=NotFound. Response body: { "statusCode": 404, "message": "Resource not found" } Client ID and secret sent in Basic authorization header.. Response status code=NotFound. Response body: { "statusCode": 404, "message": "Resource not found" }
The setup looks correct. It seems like a reference problem = like the production account and the developer account are not in sync or something. I have the same email address for both production and developer accounts and we use SSO - maybe its trying to reference production and not the developer account when its logging in? Just guessing.
I have a ticket with them, but they have note been able to help so far and they are on AEST time and I won't be able to get a response back from them for another couple of days :(
(I tried using the DocuSign Git repo API to create the connection as well - same problem)
Anyone have problems like this or know a solution? Anything else I can look at. This seems all straight forward -standard OAuth setup.
Using this setup like in the article for the demo (dev) account.
DEMO:
IKey: Integration Key [captured earlier]
Secret Key: Secret Key [captured earlier]
Authorization URL (DEMO): https://account-d.docusign.com/oauth/auth
Token URL (DEMO): https://account-d.docusign.com/oauth/token
Refresh URL (DEMO): https://account-d.docusign.com/oauth/token
Scope: signature extended
This will connect to a single DocuSign user (like a "service account"). It will not prompt each user for their credentials. You will need 1 generic user setup within your DocuSign account, without SSO (you can setup an exception user in DocuSign admin. This is best practice when setting up SSO as a fallback in case SSO fails to login as well).
The envelope will be sent from that generic user, not the actual user. This is common practice with some "system level" integrations.
Also, are you connecting a DocuSign "demo" or production account?
I ask because there's two connectors for power automate - "DocuSign" (for production) and "Docusign Demo" (for demo). I would recommend doing it all in demo first, as the "client id" (aka "integration key") needs to go through a go-live process to be promoted from demo to prod (see the link in the guide).
So, last week my application that connects to Office365 using IMAP suddenly stopped working with Basic Authentication (gee, thanks for the early cut-off with no warning Microsoft). I tried troubleshooting that issue for hours, and could find literally nothing wrong since everything was already configured to work with Basic Auth (and was working). I do know they've been threatening to shut-off Basic Auth for a while now, and with a new looming deadline of October, 2022.
After getting nowhere with why it suddenly stopped working, I finally decided to just bite the bullet and switch to using the XOAUTH2 authentication mechanism. After a day and a half of trial-and-error to put together the right series of incantations to make that work correctly, I got that working. Microsoft's documentation is borderline garbage with conflicting information and confusing examples. That and a complete lack of any reasonable error response from the IMAP server about why authentication failed (just the lovely "NO AUTHENTICATE failed" message).
Note: I am using the Client Credentials flow and the AccessToken is being issued to expire after 1 hour.
So, here's the question:
My app basically loops on IDLE and/or processing new mail. When the AccessToken expires, the server will respond with a "Session invalidated - AccessTokenExpired" and then just close or reset the connection. This does make sense, but I would prefer to keep the connection open and just re-authenticate.
My first idea was just re-issue the "AUTHENTICATE" command 1 minute before the AccessToken expired. Server did not like that and gave me a "Command received in Invalid state." response. Hrmph.
Second idea was 1 minute before the AccessToken expired, issue a "LOGOUT" and then "AUTHENTICATE" again. However, Microsoft's IMAP server responds to the "LOGOUT" with "OK" and then closes the connection... Hrmph.
C: R0001 AUTHENTICATE XOAUTH2
S: +
C: <username:token base64>
S: R0001 OK AUTHENTICATE completed.
C: R0002 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4REV1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS MOVE ID UNSELECT CLIENTACCESSRULES CLIENTNETWORKPRESENCELOCATION BACKENDAUTHENTICATE CHILDREN IDLE NAMESPACE LITERAL+
S: R0002 OK CAPABILITY completed.
C: R0003 SELECT INBOX
... <59 mins later> ...
C: R0021 LOGOUT
S: * BYE Microsoft Exchange Server IMAP4 server signing off.
S: R0021 OK LOGOUT completed.
Connection closed.
I did notice there's a server capability called "BACKENDAUTHENTICATE", but there literally is no documentation that I could find on what the heck that capability is about or used for...
What I would really like to do is just issue something like "AUTHENTICATE" again, but with the new AccessToken and then go back to the IDLE/new mail loop. Or maybe a "REAUTHENTICATE" command (that doesn't currently exist).
And yes, I have read RFC4959, RFC3501, and even RFC2222 (as well as a lot of SO posts).
For now, I have just accepted the fact that the connection is going to close and then I'll turn around and re-open a new one...
I would love to hear if anyone has any other bright ideas.
I am considering re-implementing the application using their Graph API, which might be the slightly better long-term option assuming we stay on Microsoft Office365.
I did like that IMAP was a more generic and broadly accepted mailbox protocol and why I chose it in the first place.
Let me try to answer some of your questions.
I do know they've been threatening to shut-off Basic Auth for a while now, and with a new looming deadline of October, 2022. After getting nowhere with why it suddenly stopped working
Microsoft says that in early 2022, they will pick tenants (using some unpublished criteria) and disable basic authentication for all the chosen protocols except SMTP AUTH for a period of between 12 and 48 hours. SMTP AUTH is excluded because it might affect important operational aspects like multi-functional devices or PowerShell scripts sending updates about a job’s progress. When the period expires, Microsoft will enable basic authentication automatically.
Please refer to this link : https://office365itpros.com/2021/09/24/basic-authentication-exchange/
The Basic Auth has been already disabled for many of my clients, so the above statement is valid.
I am using the Client Credentials flow and the AccessToken is being issued to expire after 1 hour.
Using the Client Credentials flow, you do not get a refresh Token which can be used to get a valid Token without losing/dropping/closing the connection.
Based on the RFC6749 (https://www.rfc-editor.org/rfc/rfc6749#section-4.4.3), a refresh Token should not be included.
As #Max mentioned in his comment, "RFC3501 does not include any ability to reauthenticate an existing connection".
Since you don't want to lose/close the connection, I would recommend to use the
Oauth2 authorization code flow (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow), which will give you a refresh Token as well.
Also, I would recommend to use the Microsoft Authentication Library (MSAL) (https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-overview)
The Microsoft Authentication Library (MSAL) enables developers to acquire tokens from the Microsoft identity platform in order to authenticate users and access secured web APIs. It can be used to provide secure access to Microsoft Graph, other Microsoft APIs, third-party web APIs, or your own web API. MSAL supports many different application architectures and platforms including .NET, JavaScript, Java, Python, Android, and iOS.
I am developing a web-based application that will allow my trusted staff to edit the titles, descriptions, tags, etc. of my YouTube channel. In attempting to "Opt In" to my own application, I was sent to the callback URI with an error message:
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure. You can let the app developer know that this app doesn't comply with one or more Google validation rules.
Some history - when I first attempted to obtain a code to exchange to an authorization token, it actually worked! However, as I was writing the code to harvest the code and exchange it for the authorization token, I repeated the "Opt In" process multiple times. Before I was ever able to perfect my code to exchange the code for an authorization token, I began getting the error message to the effect that the app is insecure and cannot be signed in to.
More history - after reading a Stack Overflow article describing something similar, I deleted the project, created a new project, generated a new Client ID and Client Secret, and then repeated the test with the same failure.
I am the only Test User of the app. I can't find any notification in my console alerting me to nature of the security issue triggering the failures. I have reviewed the OAuth policies at
OAuth 2.0 Policies
and cannot find anything even remotely wrong.
What is wrong and how can I fix it?
I also had the same issue.
For me, it turned out that my redirect_uri is not valid. The redirect_uri that gives error:
http://localhost:8000api/vi/oauth/google
What are wrong in my case:
I should put a / before api.
vi is different from what I registered on GCP. It should be v1
I would suggest you to print out the redirect_uri when your app is performing code exchange, and verify every single characters carefully.
Additionally, check out the documentation of Redirect URI validation rules on Google to see if your redirect_uri comply with all the rules.
You probably changed the port where the project is running or you did not define the address where the project is running in Google Cloud.
Google Cloud → APIs and Services → Credentials → OAuth 2 Client ID → change Authorized JavaScript origin to the port that your app runs on the local or shared host.
The URL may take time to define, so it may not work right away, so you can also create a new credential.
For me the redirect_uri was correct, but as a result of an error, the access code was requested for a different client ID.
I've been working to setup Oauth communication for an auto-emailing node.js web app using nodemailer. (I don't wish to use gmail's Less Secure Apps setting).
I've taken steps to get the client id, secret, and refresh token from the oauth playground, and have set up the web app to use a stored refresh token to request new access tokens when it first loads.
It is able to send emails (for about 7 days), then I get error invalid status code 400 on client side, and/or invalid grant on server side.
Going back to google playground and getting another refresh token, then updating it in environment variables, solves this for another week. But I'd like to solve this indefinitely.
I read somewhere "A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of 'Testing' is issued a refresh token expiring in 7 days"... so last week I switched the app to "In Production" (at console.cloud.google.com) and tried having it verified with google. This week, the same issue has recurred suggesting that wasn't the right fix, or that it wasn't yet verified with google.
I don't know if this was done correctly, nor do I know if this is the true solution to this expiring/revoked refresh token, or invalid grant.
I've also come across these explanations:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
The client has reached a limit of 50 refresh tokens per account if it's not a service account.
(I didn't make ANY changes during the week, so...not sure why these would have changed)
Is the issue the refresh token?
Or the status of the application?
Would it be dns/cname/cloudflare server issues?
For those who have the same issue in the future:
It turned out that google verification wasn't necessary.
It seems like the refresh token expiring after a week or 7 days was due to the placement of the oauth2Client.setCredentials() function call and accessToken variable.
Calling setCredentials() and obtaining the access token INSIDE the SendEmail() function (at runtime, just before sending email, rather than at application start/spinup time) seemed like it enabled the code to more dynamically generate the tokens it needed. After 12 days, it still seems like its working so I'd call this a success.
My guess at why it wasn't working before was because setting credentials outside of a function meant that code only ran once on server/application startup. It would then store the obtained access token in a const.
The access token would eventually expire, and even if called again/later inside of a function to obtain a new access token, it would be unable to change the value of a const property/variable, and so the call would inevitably fail after a week when it failed to renew.
Hope this helps anyone else having a similar issue.
My apologies for the run-on sentences.
There are a lot of causes for invalid grant it sounds to me like your refresh token is expiring.
If your project on google developer console is still in testing, has not been moved to published and has not gone though the google application verification process then refresh tokens have a max two week life span after which they will expire which may explain your invalid grant. The thing is there is no official word from google that this is happening its just what a lot of developers are seeing these days.
Another one is with gmail scopes if the user changes their password this will also cause the refresh token to expire.
I'm writing a Slack app that adds Slash commands.
Every time I go through the OAuth flow, when I try to exchange a temporary auth code for an access token, I get the following JSON response:
{"ok"=>false, "error"=>"code_already_used"}
and despite that error message, the two slash commands provided by my app do get installed on the target Slack team.
The desired outcome is: I get a successful response from Slack's API, which contains the access_token and scopes for which the token is valid.
Troubleshooting I've tried so far:
Revoked permissions from my app & uninstalling from target team before trying again
Requesting additional scopes (e.g, commands,channels:history,users.profile:read which I don't need, instead of just commands) to see if that would cause the API to return an access token.
I am able to install on other teams outside of the original team I used when creating the app, but with the same api failure
Any suggestions for how to get the API to return an access token? Thanks in advance!