I am currently experiencing an issue regarding JWT refreshing causing a 401 and thus a logout on the client-side. A JWT refresh token that was once used is discarded and can't be used for subsequent refreshes, that seems to be the standard so that's what I'm going with, however it's possible that you send out a JWT refresh and by the time the JWT refresh response comes back that the app (Android or iOS) is already shut down. This causes that the next time you open the app that you're using an outdated JWT token causing a 401.
This has been shown to happen when you accidentally open the app, notice you opened the wrong app and by the time you closed it already sent out a refresh on the JWT token but you close it early enough for the response to never come back (this issue is exacerbated when you have a weak internet connection as the response time is even bigger) and thus next time you send out a refresh the refresh JWT is no longer valid.
If it helps the situation in any way, we're developing the app in Flutter/Dart for both Android, iOS and Web. The server-side is created using NodeJS and Express.
This can also happen if you just close the app when the app just sent out a refresh token after normal usage of the app so this seems like an edge-case that I am not sure how to fix.
Previously we used Firebase Auth for the app, but we moved away from that, and Firebase Auth seemed to never log out users due to issues like this so there must be a solution, only I don't know what the solution would be.
Is there anything I am missing that could help solve this edge-case?
Thank you for your time!
Related
I've developed a Google Smart Home action and it is live on the Google Assistant and Google Home app.
Account Linking, Device Creation, and Device Control seem to all be working fine.
The one complaint we receive is that sometimes, after around a month, the devices seem to lose connection to the Google Assistant app.
When attempting to send a command, we get the most message "Sorry it looks like the is unavailable right now." The devices still show up under Home control and the action still appears under "Linked". The command event never reaches our Lambda function.
Does this problem description sound like a red flag towards any aspect of the integration?
I'm wondering if it is maybe a token that isn't being refreshed correctly? So that after the month, Google kicks us out? I only think this because of the consistent time frame the error occurs at. No idea though haha. I don't remember seeing anything in the docs or the sample action (https://github.com/actions-on-google/smart-home-nodejs) that mentioned preventing expirations from occurring.
Thank you for your help in advance!
You can review the error logs for your project, which will indicate if errors are occurring due to account linking or something else related to your intent fulfillment.
I'm wondering if it is maybe a token that isn't being refreshed correctly?
This is a reasonable place to start, and your error logs will indicate if there are account linking errors. For example, your OAuth server may be expiring the refresh token before a new one is delivered to Google Assistant. You can find more details on implementing OAuth token exchange in the documentation, including a note about rotating refresh tokens.
Note that Google Assistant generally only refreshes the access token when an intent needs to be sent (i.e. not immediately once the token expires). Sometimes this can also affect the refresh behavior of your OAuth server.
I am creating an iOS app with Spotify playback with a django backend. This is my first programming project, and I am a little hung up on oauth2. I know that I need to do the authorization code flow on the server side to obtain refreshable user tokens.
I set up django-allauth on my django project, and managed to get it working to authenticate Spotify users despite the limited documentation for Spotify. I can call localhost:8000/users/spotify/login and the code will be refreshed and a vlid access token is stored in the database (made authorized request on Postman). I believe this will work when I deploy the changes to heroku as well, I just have not yet.
Getting back to my iOS app, I am trying to use the sdk to stream songs. I start the SPTAudioStreamingController.sharedInstance() with my client ID, no problem, and then try to login with access token hard coded, with no success. I know that I am missing something, probably involving the session that is returned when authentication is handled completely through iOS. I am hoping for clarification on how to complete this implementation and log in on the SDK properly using the access tokens stored in my django backend. This is the function that attempts to set up spotify and login. It is called in the app delegate.
print("Setting up spotify")
SPTAuth.defaultInstance().clientID = "hardcodedclientID"
SPTAuth.defaultInstance().redirectURL = URL(string: "hardcodedredirectURL")
SPTAuth.defaultInstance().sessionUserDefaultsKey = "spotifySessionKey"
SPTAuth.defaultInstance().requestedScopes = [SPTAuthStreamingScope, SPTAuthUserLibraryReadScope]
do {
try SPTAudioStreamingController.sharedInstance().start(withClientId: "hardcodedclientID")
} catch {
fatalError("Couldn't start Spotify SDK")
}
print("shared instance started")
SPTAudioStreamingController.sharedInstance().login(withAccessToken: hardCodedAccessTokenFromDjango)
print(SPTAudioStreamingController.sharedInstance().loggedIn)
I have set up all the app settings I need to, per the two tutorials I followed here and here. I know that I will not be able to hard code the information like that, but I was under the impression that I should be able to login(withaccesstoken:) simply using the access token I had. I am trying to find the best practice for sending my acces token through My Django REST API and then authenticating the SDK with it.
I ended up being able to get the same code to work. I added a session variable and set it, but the main problem was that django-allauth defaulted to requesting no scopes, I changed the source code to the scopes I needed and the process went much smoother. I believe I can access my access token through my api and that will be enough to initialize everythign client side, which is wa
im developing a app using a REST API, im using the well known JWT approach to secure my services but there is something bothering me and it is the fact that i can see my token in the resources tab in chrome (firefox, IE .. etc) i've set the token expiration time to 30mins and it just came to my mind that pretty much any developer can stole my backend url just by inspecting the javascript code and also stole my token from the said tab so he will have pretty much 30mins (with luck) to hack me up somehow .. is it (the localStorage) really the only place to store the token?
An attacker that has access to your machine would have access to localstorage just as easily as cookies. Even Multi-Factor Authentication can't help you deal with someone getting control of your authenticated client (browser in this case).
I'm currently working on some lightweight code to correctly wrap usage of the Facebook Unity SDK for some client applications, and I've run into a minor problem, wherein the Facebook Unity SDK docs suggest that I shouldn't be doing what I am. Basically I want to know if what I'm doing is right.
To preface - the documentation for FB.Logout suggests that a client app should never really need to call it, as it will log the user out of facebook globally, in contradiction of their expectations. (See https://developers.facebook.com/docs/unity/reference/current/FB.Logout)
In my code when I receive an error from facebook which could mean the token has been invalidated, I ping off a simple request which should always succeed if the user's token is still valid. If this fails, I invoke FB.Logout, because without doing so, calling FB.Login again will simply fail - the user's token will remain the same, and the Login call will succeed.
Behaviourally everything behaves as I would want - calling FB.Logout just clears the local state and lets me go back to my 'initialised but not logged in' situation.
Basically, I want to know if this is expected behaviour, and whether, contrary to the documentation, this is the correct case for calling FB.Logout.
Cheers,
Jeremy
FB.Logout will log you out of Facebook and your app on the web.
On mobile, it will sign out from your app.
This is by design, and your implementation is correct.
On Web, this method will log the user out of both your site and
Facebook. On iOS and Android, it will log the user out of your
Application.
On all the platforms it will also invalidate any access token that you
have for the user that was issued before the logout.
cf. https://developers.facebook.com/docs/unity/reference/current/FB.Logout/
I am using the standard commenting link and facebook api from github. For some reason today it decided that any page with comments will go into an infinite refresh. I added the line for Oauth 2 and it didn't solve the problem.
It has worked fine for several months, but the problem started today for no reason. Only happens when the person is logged into facebook.
Most commonly I find this occurs because something in the session borked up.
So you have a partial connection and it loops to complete the connection but its expired and doesn't clean down properly.
Clearing your session cookies and restarting the session, and it not looping will indicate this is the problem and additional code will need to be added to detect a bad/partial session.
Possibly just a bug in the code, or a temporary problem with the Facebook API.