I have developed a Testing APP (this APP has testing status because this is not published) and, as far as I am concerned, these is no other way to get a refresh_token to use this APP apart from Google Playground. Is it right?
The problem we are facing is that the token generated by Google Playgorund lasts only 7 days and we are wondering if is there any other workaround to get this refresh token without spending a few minutes weekly.
Thank you in advance!
as far as I am concerned, these is no other way to get a refresh_token to use this APP apart from Google Playground. Is it right?
Well no your supposed to write your own application to authorize to the api. your code can authorize to the API using your client id and client screen. Understanding Google OAuth 2.0 with curl
The problem we are facing is that the token generated by Google Playgorund lasts only 7 days
All apps that still have a testing status in Google cloud console. Have their refresh tokens expired after seven days. This has nothing to do with Playground.
Actually my research says that what they do is just revoke the users grant to your access. This is probably faster for them then revoking any refresh tokens created.
Directly from the docs.
experation
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.
If you use Google Oauth playground by itself to create a refresh token. Last i checked refresh tokens would expire after only a couple of days, this is because its only intended to be used for testing not a permanent solution.
Now if you configure oauth playground using the screen below to use your personal Client id and client secret for your project you will then be restricted to the seven day refresh token as your project is still in testing.
The solution to getting a refresh token that lasts longer then seven days is to put your app into production. TBH if your still in development / testing you really don't need a refresh token that lasts longer your test users can just authorize the app again. A seven day refresh token is long enough to test your authorization flow within your application as access tokens expire within an hour.
Related
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.
Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.
I'm writing an app that keeps track of a user's friends. I want to be able to verify his friend list when he isn't online. Is there a way to do this? In other words, do API calls again an account that was verified while the user is offline?
You can use a long-lived access_tokens to access Facebook on a user's behalf for a period of up to 6 months. This means you can access the user's friend list or perform other operations as long as the user logs in one in a while.
This tutorial covers how to get a long-lived access token using the Facebook PHP SDK.