I'm working on a project that has the following requirement: Sessions should never last more than 90 days.
I'm also using Firestore, and by extension to authenticate users, Firebase Auth. I want to give access to Firestore to my android and ios clients, for 90 days maximum. After that duration the session should automatically expire.
I initially thought custom tokens were the solution, because I thought they were just a different term for ID tokens. But in reality they can be used to get a refresh token that never expires.
I therefore thought about managing the refresh tokens myself, by:
issuing my own refresh tokens
verifying their validity
creating a new custom token
exchange the custom token with an id token and refresh token on the back end
only return the ID token to the client
the client would give it to firestore.
I don't mind managing expiration and renewing the id token myself on the my back end.
Now my problem is that when I look at the official SDKs for firestore on Android and SDKs, none seem to allow for just attaching an id token to requests?
Is there a solution to my issue? Or maybe even a better approach?
Thanks!
Related
I have a question on "make the browser send out a request to exchange for a new token at the sixth day. Accordingly, on the server side, create a restful API named /token/extend which will return a new token if given a valid token."
Let's assume that I implement this concept. When token is about to expire, we will generate new valid token if old valid token is provided.
Now, let's assume, Hacker gets the token. He uses this token to communicate with APIs. Hacker communicates for 6 days. On 6th day, our "/token/extend" API will generate new token for him so he can communicate for another 6 days, and probably forever. Will this situation occur? or Am I missing something here?
The general way you would force your users to obtain a new token after 6 days would be by simply setting the exp field (expiry) in the claims of the JWT to expire after 6 days. The exact mechanism by which users would use to obtain a new token depends on your implementation.
The most basic implementation would be to just let the incoming request on the sixth day to fail, forcing the consumer of the API to redirect to the login page. From there, the user would have to login again to obtain a new valid JWT. A more elaborate method would use refresh tokens. With this approach, when the user first logs in, he would receive an authentication token with a 6 day expiry (as before), but would also receive a refresh token which would expire a little bit later. On the sixth day, when the user tries to access a service, the request would again fail. However, in this case, the consumer (e.g. a website or mobile app) could take the refresh token and request a new access token under the hood. This would be a more seamless way of handling the mandatory 6 day expiry. Note that with the refresh token approach, the user might never know about the 6 day expiry.
Regarding your concerns about hackers obtaining other people's tokens, you should mostly just forget about this. If someone stole your wallet, there is all sort of havoc he could do to you, e.g. using your credit cards, stealing your identity, etc. The same could happen with a stolen/sniffed JWT. The best practice here is to just make sure you are using two-way SSL for all communication, and also encourage your users not to use your services in places like Internet cafes.
I'm working on a digital board for meeting rooms. Every board, set outside the door of the meeting room, displays if it's occupied or not and the following meetings, according to it's calendar.
I followed this tutorial to create a JavaScript single-page app.
The problem is that after a while (less than 1 hour) I have to do the log-in again. I'm really struggling to find a solution to avoid it at all or reduce this frequency as much as possible.
Looking around it seems that working on the life of the Token is the answer. Refresh it or, even better, set it that never expires (until-revoked).
I've tried with PowerShell, following this guide but it doesn't work for the v2.0.
Azure AD does not support infinite lifetime Access Tokens. The hard limit for an Access Token lifetime is 1 hour.
However, Azure AD do support infinite chaining of the refresh token for new access tokens. When you modify the configurable token lifetime property and set it to until-revoked you are really doing this for the refresh token.
You must make sure you have proper logic in your code that tracks the expiration time of the access token, and requests for a new access token using the refresh token when the old token expires.
I'm making an application that among it's task will use the REST API in KeyVault. I already have functions written that will query the KeyVault for the secret without an issue.
I also have functions written to request an OAuth token from AAD, following the documentation on this link:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
What I'm not sure about is; Since the application is going to be installed on hundreds of computers when a token expires and the function to refresh the token is called chances are that more than one PC is going to make the POST. What is the best practice for a scenario like this? Should i just configure an exponential back off after a refresh token function is called?
The app installed on the machines will not have the ability to talk to each other.
The only way I can think to do this is to use a logic app as the broker but that would defeat the purpose of the KeyVault.
The document you provided is using the code grant flow to acquire the access token. This flow requires users to login to acquire the token. And did you mean all the PC you installed will use the same account to acquire the token?
If yes, you can design you own token cache. For example, you can using an SQL server to store the cache. Then the app will search the token/refresh token in the token cache before it sends the token request. And if the token is expired, you can refresh it. In this scenario, all PC will share the same access token since they are sign-in with same account.
If not, you need to refresh for the every PC when the access token is expired. Because the access token is different from each user.
So after some testing and verifying with MS it looks like the documentation on the link is outdated. When a token is generated it has a lifetime of 8 hours (this is configurable) so every time I make a request to /token a new token is handed out, since the time window is small I don't need to worry about token refreshes since PCs won't be on for over 8 hours.
The other part of this is that i built a function to test the validity of the existing token, before i query any azure service i test the token validity, if it fails a new token is requested. Since the token lifetime windows are short and each machine gets it's own token (i thought all machines were getting the same token, code error on my part) this is a non-issue anymore
I have a web app built on oAuth2 that has been in production for 5+ years. Users Authenticate and Authorize with Google and grant my application access to the Google Analytics data.
All of a sudden I am seeing a surge in failures when refreshing my users oAuth2 tokens. This is the call:
https://accounts.google.com/o/oauth2/token
Passing these parameters:
client_id=xxyyzz
client_secret=xxyyzz
grant_type=refresh_token
refresh_token=xxyyzz
This seems to be be on accounts that are less active (i.e. it could be 15+ days between instances where we make calls on their behalf). I have to reach out to them and have them "ReAuthorize" against Google to get things working.
1) Did something recently change with Google oAuth2 or the GA Core Reporting API?
2) If access tokens are not refreshed after some time period will my refresh token become invalid? i.e. should I make calls against all accounts even thought I don't need the data; just to keep the refresh token from going stale?
Thanks,
Mark.
Update on Scope
It was requested to provide the scopes in play here:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/analytics.readonly
11/17/2016 Update:
We did find an issue that resulted in some tokens being purged. We are working on to make sure it doesn't happen again. Unfortunately there is no way to restore the tokens that were deleted and your users will have to reauthorize again.
11/11/2016 update:
We are actively investigating the issue. You should ask your users to re-authorize the application.
(from Google Identity/Auth team) We would like to investigate this a bit more to make sure our system is working as intended. Other than the token revocation (with certain scopes) on password change, we haven't changed the token revocation policy.
Would you please ping me via my G+ profile?
I am working with Oauth2.0. In that i could able get the access_token and instance_url. Is there any expiry time for these two.
Can I store them and use it for all my REST calls without getting the new access_token and the instance_url. Is it possible for me to use it for long hours or even days.
The access token is only valid for the length of a session (as defined in the Salesforce Org's settings — I believe the longest this can be is 8 hours without activity), as it's actually a session ID, that said, you should also be given a refresh token. The refresh token has a much longer lifetime and can be used to authenticate the user once the session has expired, without them having to enter any credentials — this allows you to do it in the background without them even having to concern themselves with the login process.
model metrics do a good job of explaining the token flow here.