One of our customer using the 'Habitat HomeLink' launched year ago, They have been observing after using for a month thermostat devices disconnects in google home and they have to re-link their devices in order to work again.This keeps happening after several weeks.
Please let me know the cause for this issue or any suggestion on this.
Expected the devices stay connected in google home even after many months
Most likely your Access Tokens are expiring after a month, and your service has an issue renewing the Access Token from a Refresh Token.
A refresh token might stop working for one of these reasons:
The user has revoked the app access.
The refresh token has not been used for 6 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 user belongs to a Google Cloud Platform organization that has session control policies in effect.
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.
More information in this regard can be found here.
Related
Trying to use Akeneo Apps https://apps.akeneo.com/how-build-app-akeneo-pim .
It's more-less clear how access token generated - as response to user in akeneo portal clicks on the connected app. but how to use Akeneo Apps for background product catalog sync between my app and Akeneo? with connector I'd just generate access token based on client id/secret stored in config, but here I need Akeneo portal to pass control to my app... How I can call Akeneo API few days after that?
Tried to see if refresh token can help but 1) it's not returned in https://api.akeneo.com/apps/authentication-and-authorization.html#step-3-get-a-permanent-access-token and 2) even if returned what if because of app downtime I miss the renewal checkpoint and the token gets expired? would need to ask user to login to akeneo
As indicated in https://api.akeneo.com/apps/authentication-and-authorization.html#token-success-response
An Access Token given to an App has no expiration date.
Basically, when an user install your application in his Akeneo PIM, your app will receive an access token that does not expire.
Store it somewhere like your database, and then reuse it anytime you want, even days later.
No need for a refresh token.
The Access Token that you will have stored will continue working until a Akeneo PIM user decides to revoke your app.
I have an app that runs in a conference room kiosk that displays the conference room's calendar. Right now the app uses the Interactive Credentials Flow to interactively get the room account's token and then fetch the calender. By managing refresh & access tokens we should never have to sign in again and re-grant access.
However - we need to deploy this app to 300 rooms. Sending a technician around to each room and signin with each room's account and grant access is very costly. Also if ever the refresh or access token goes stale or is revoked, we have to send out a tech to the conference room. Some conference rooms are in building where there is no tech in the city.
Is there a way we can do this centrally? To get an access token for a user for granted permissions, then feed this to our application?
We looked at using the "Client Credentials - Application Secrets Flow", but this requires giving the app access to the entire enterprise's calendars. This we cannot do as many of the users require high security.
I find this an interesting question.
here is the documentation on how to achieve this: https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access
You would use application secret auth, but using this, you can limit which mailboxes the graph calls can access. this would be the most elegant way I believe.
We have a situation with our Nativescript Angular App. We use OAuth 2 with PKCE for our authentication process but my team is fairly new to the world of mobile development.
From my research it would seem best practice suggests the lifespan of the refresh token should be anywhere between 2 weeks and 2 months. Currently our access token lifespan is set to 2 minutes and our refresh token lifespan is 30 mins. This means our users have to login every 30 mins using their username and password which isn't ideal for UX and we've received a lot of criticism for it.
Our login page uses a WebView so we considered also trying to auto-populate the form fields with a securely stored version of the username and password but then realised this can't really be done and isn't great for security.
So to improve the login process and make it more seamless, we're looking to setup face/touch ID with a pin code fallback. This means we'll have to push the lifespan of the refresh token to say 2 months or as long as possible — this seems like the best approach moving forward.
That said, the other problem is we also have a website which uses the same authentication server so if we change the Keycloak settings it'll change it also for the website as well which will create more work for the web team.
So my question is should we be using a separate authentication server just for mobile access?
I would suggest you to use offline tokens that never expires. Check this https://www.keycloak.org/docs/latest/server_admin/index.html#_offline-access
Basically in authentication process you pass additional scope named offline_access and instead of regular refresh token auth server returns offline token.
So my question is should we be using a separate authentication server just for mobile access?
If you use separate server (realm) for mobile app then you will have separate user, client and session collections and you will have hard time integrating additional applications with auth server.
I have a web applications and I wanted to allow users to pick file from oneDrive and submit those files. So my question is that, is there a way for me to allow for users who use my site to do this without asking them to log in for oneDrive ?.
I have a similar experience in googledrive and in there, we can do this through service account by authentication each users from the backend silently each time.
Further more, I have sign up for office 365 for business and link it to Azure and in there add few user to it via Active Directory.
Thanks in advance
One way is to use a designated account to create refresh token that has 'offline access' to the OneDrive. The offline access refresh token has a very long (or indefinite) expiry. Use OAuth 2.0 to create the refresh token.
Every time a user needs to browse the OneDrive, use the refresh token to request a short-term access token (again, this is OAuth 2.0). You can use that access token to access the OneDrive.
Unfortunately, my finding is that offline tokens have full read/write access - read only access doesn't seem possible.
First of all, thanks you for your time and help.
I have an app engine application that use federated login. However it is giving me 500 Server Error for the past 2 hours.
Is it a known issue with this service at this momement?
Thanks again.
Bill
As per AppEngine's authentication documentation:
(Experimental) Open to all users with an OpenID Provider:
If your application uses authentication, anyone who has an account with an OpenID Provider may sign in.
Google has announced deprecation of OpenID2 a while ago and sunset the corresponding APIs last week, thus unfortunately these Google authentication APIs are not available through AppEngine any longer.