Google home action account link failed - oauth-2.0

Account linking problem for only some of our users, most users link account normally. For users linking account failed, they just see the login page refreshed to empty account name and password.
From our server log, we found for users that fail to link, the user accesses our server successfully and got OAUTH code, but after about 15 seconds, google server accessed our server to exchange the code for a token. However, the code has expired by this time.
For successfully linked users, the time between issuing the code and exchanging it for a token is about 2 seconds.
Does anybody know how to resolve the problem? Thanks.

It sounds like the expiration time for the authorization code has been set to about 10-15 seconds. While the auth code should have a short lifetime, 10 seconds is way too short. The recommended lifetime should be no more than 10 minutes, not 10 seconds.
Consider that this code needs to be sent back from your server to the user, from the user to Google, and then from Google to your server. On some networks, each step might take more than a couple of seconds, particularly since it must be done over HTTPS this adds both network and processing overhead. Each step adds just a few fractions of a second - but they can add up on some devices!
There could also be a slight clock skew between the issuing server and the processing server - likely not much, but when you have a lifetime of a just a few seconds, even a 1 second skew could be too much. If the two are very out of skew, then this could be the cause of your problem as well. Make sure the clocks on your servers are at least reasonably in sync.
The best solution would be to increase this timeout on your server when you generate or accept the code. You may have thought you were specifying 10 minutes for a configuration field that actually accepts seconds.

Related

Azure AD Sign in + OWIN + MVC/Webforms + Timeout + Refresh Token

I have successfully followed this guide "Tutorial: Add sign-in to Microsoft to an ASP.NET web app", and introduced Azure AD logins to our old WebForms/MVC application. This is working fine in terms of logins/logouts. This is using AD rather than B2C.
https://learn.microsoft.com/en-gb/azure/active-directory/develop/tutorial-v2-asp-webapp
The problem we are now facing is our users are being logged out between 60-90 minutes - I think to do with this: "The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average)"
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#access-token-lifetime
My question is, how do I deal with this correctly?
I want users to be logged in for a period I select.
If they are active I want them to stay signed in.
I want sliding expiration turned on, and I want to be able to increase the access token to longer than 60-90 minutes.
I've seen on the Startup.cs class I can set these two properties on UseCookieAuthentication, but no cookie is created and the settings do not come into affect.
ExpireTimeSpan = TimeSpan.FromMinutes(1),
SlidingExpiration = true
Or another idea is I somehow need to refresh the token on posting the page back.
I've also seen something around caching the tokens.
Please can someone shed some light on this?
I can't find any other documentation on how to implement this correctly and users having to login to an application every 60 minutes that the use all day is proving very frustrating.
Thanks

AWS Cognito Incorrect Password limits

We are currently working on a mobile application which is currently in beta version and plan to get it released to App Store very soon and this primarily supports only iOS mobile devices
Recently one of the external users had frantically typed a wrong password repeatedly in login screen which further exceeded the limit, resulting in an internal server error and finally locked the user out of the app
The default error messages come from AWS Cognito and the user is required to fill in the phone number and password to log in to the app
How many times will AWS Cognito allow the user to punch in incorrect passwords. Is there a limit to it
Is there any documentation which clearly explains my problem
Is there a way to let the user know at the first instance say., that there are only 5 attempts to try
Any help is much appreciated
According to AWS Cognito docs,there are no limits on login attempts, however they do secure login endpoint with request rate limiting and exponential timeouts:
We allow five failed sign-in attempts. After that we start temporary lockouts with exponentially increasing times starting at 1 second and doubling after each failed attempt up to about 15 minutes. Attempts during a temporary lockout period are ignored. After the temporary lockout period, if the next attempt fails, a new temporary lockout starts with twice the duration as the last. Waiting about 15 minutes without any attempts will also reset the temporary lockout. Please note that this behavior is subject to change.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html

Yammer - Users login stopped working

A significant number of users are getting the error message of 'GetAccessToken - Unauthorized error: Your network is not allowed to request an OAuth token for this Application' whilst trying to log in to our application.
I have checked and tested, and they are accessing the correct network with the right credentials. This is happening to almost every person, so I don't believe this to be a coincidence.
This has only begun to happen in the past 24-36 hours. Are there any suggestions as to why this error is occurring, has something changed that I may have missed?
Thanks!
Couple of possible scenarios:
It is likely that the new simplified SSO is rolling out for these
users, which means they will use their O365 credentials to login to
Yammer from now on. Every user will need to reauth external apps (I
had to for our own apps also when this change occurred for us last
week).
Tokens also can expire when user's passwords expire, so if
they have a mandatory time interval to reset this could trigger an en masse need to reauth
Make sure your JS Origins are specified in your app details if you are using the Login with Yammer button and/or the JS SDK. http://naomimoneypenny.com/2015/02/11/yammer-apps-javascript-origins-update/
There isn't clear and definitive guidance regrettably from Yammer as to why and when tokens expire. Just that they do e.g. from https://developer.yammer.com/v1.0/docs/oauth-2
Once the token expires, you will need to re-run the steps above to generate a new code and access_token.

Internal_failure while getting refreshtoken using code?

We are getting internal_failure error message while exchanging code to get refresh token. This error doesn't occur all the time for all the accounts. This happens only while authenticating with a few Google accounts and that too like 5 to 6 failures for every 10 authentication requests no matter what the client_id is. We have a test account and is reproducible too frequently in this account as well.
{
"error" : "internal_failure"
}
How often are you making these requests? You are probably running into the per account quota limits.
In real life, any account would not be doing a lot of code to refresh token conversion. The expectation is that you do that just once per application.
So, if you have test/monitoring accounts, they will run into these issues. The best is for you to monitor and test only your site/code.
internal_failure is an authentication server outage. which can be tracked on
Cloud Status or apparently also APP Status although I am not seeing it there it may only be GSuite issues are there.
There is nothing that you can do but wait for the server to return.

PayPal Instant Update API not working on HTTPS

We are building an online store that is based on Spree and hosted on Heroku. We want to make the checkout as easy as possible so we decided to use PayPal Express Checkout, and Instant Update API to determine the shipping cost.
When we tested the checkout process over HTTP, everything works perfectly - when the user enters his shipping address, PayPal queries our server in the background and obtains the shipping costs.
However when we switched to SSL, the shipping cost just doesn't update and reverts to the default flat-rate. I cannot figure out what is wrong because everything is the same, except this time the app is accessed through HTTPS, i.e. https://myapp.herokuapp.com
I have check the logs and I see that PayPal's server did make the query, but the shipping cost just don't update on PayPal's checkout page.
Any thoughts on what's wrong?
Update:
After further testing, it seems PayPal is not obeying the timeout set in the transaction setup. We added a simple "sleep(x)" to the callback method to artificially induce some delay (by x seconds), and even over normal HTTP, just 1 second delay is enough to caused PayPal to ignore the response.
The max timeout is supposed to be 6 seconds, but in reality it doesn't seem to be the case at all. And couple that with HTTPS (which take longer to establish a connection), it is probably why the callback was failing in the first place.
I have submitted a ticket to PayPal, but I'm not sure if they will respond or do anything about it...
It appears there are many reasons that PayPal could ignore the returned shipping options from the callback.
I'd like to see something on PayPal's site that would keep a history of recent calls to the callback with the returned response and reasons for rejection - somewhat similar to the useful IPN history.
I'm glad you posted your real domain name here because you've pretty much confirmed my suspicions.
I'm pretty convinced the problem is that you have a wildcard SSL (I see your certificate is issued to *.herokuapp.com) and not just an SSL for a single domain.
I am having the same problem with a UCC certificate for www.MicroPedi.com which is a 5 name UCC certificate. PayPal just flat out refuses to even make any calls to it (I have logging and nothing is coming through except when using the sandbox).
To confirm this I have a previous Express checkout implementation that is working just fine (with a single SSL) and I pointed my new application to that old URL and it magically started working again. That is a single name SSL - in fact it's one of those expensive green bar certificates.
I've written directly to PayPal support, but right now the only thing I can think of doing as a workaround is writing some kind of proxy page that will just redirect from the good domain to my UCC domain.

Resources