refresh-token

So I just spent the last few days trying to figure this out and am asking this question so that I can answer it for other people who are having problems. First, the google documentation is TERRIBLE and uses different oauth2 libraries depending on which of the many google API examples you are looking at. It is often self-contradictory and sometimes straight up has code in it that doesn't work. Oh well. so my questions were basically: how do I use the google api libraries to have my users grant me access to their google accounts? how do I store the oauth2 access tokens that google returns so

Thanks to this answer I am able to connect to Firebase 3 via HTTP REST API and an email/password. Logging in with this API returns an access token that is used to access the Firebase Database. This access token expires after 1 hour. A refresh token is also returned after logging in, which I can use to refresh my access token. Here is what I am doing specifically: Method: POST URL: https://www.googleapis.com/identitytoolkit/v3/relyingparty/verifyPassword?key=<my-firebase-api-key> Payload: { email: "<email>", password: "<password>", returnSecureToken: true } Response: { "kind": "identitytoolkit

While testing the security of one of our product, a web application, using the REST API of Firebase we got surprised when we realised that refresh-tokens never expire in the V3 of the Firebase implementation, allowing any refresh-token to create new tokens forever . While local-storage seem a reasonably safe solution today, we are concerned by the possibility that it could fail tomorrow , even for a short amount of time, and that we cannot stop someone from using any of these refresh-tokens. Two factor authentication will help mitigate the issue, but the first step would become compromised

i have to confess i've had this question for a very long time, never really understand. say auth token is like a key to a safe, when it expires it's not usable anymore. now we're given a magic refresh token, which can be used to get another usable key, and another... until the magic key expires. so why not just set the expiration of the auth token as the same as refresh token? why bother at all? what's the valid reason for it, maybe a historical one? really want to know. thanks Ryan Boyd The referenced answer (via @Anders) is helpful, It states: In case of compromise, the time window it's

I have a program that integrates with the YouTube Live Streaming API. It runs on timers, so its been relatively easy for me to program in to fetch a new Access Token every 50 minutes with a Refresh Token. My question is, why? When I authenticated with YouTube, it gave me a Refresh Token. I then use this refresh token to get a new Access Token about once an hour. If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires. So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole

In my application, I return an access token and a refresh token when a user logs in successfully. The expiration times for access and refresh token have been set to 10 and 40 minutes respectively. (I should do some more research on those values. This is just for testing) I used the implementation described in following article http://www.svlada.com/jwt-token-authentication-with-spring-boot/ Let's say I invoke a request to the server after 10 minutes of the login in. Since the access token is expired, I am getting 401 error response. However, as a beginner, I find it difficult to understand