I want to know how much time it takes for the Imgur API refresh tokens to expire. If they don't expire from time, what causes them to expire?
The refresh token of the imgur API does not expire, check the official documentation on https://apidocs.imgur.com/#oauth-20-overview:
refresh_token: is used to request new access_tokens. Since access_tokens expire after 1 month, we need a way to request new ones without going through the entire authorization step again. It does not expire.
Related
If I understood the refresh token rotation right, it means that every time we request a new access token, we also get a new refresh token. If a refresh token is used more than once - we invalidate all the refresh tokens that a certain user previously used, and a user has to go through the authentication process again.
Does it mean that we need to store all the refresh tokens (all the old ones) in a database?
Can't we simply store the last refresh token, only one (that wasn't used yet), and with each request to get a new access token we would check if the refresh token sent in the request is in the database, and if so, we would create a new access and refresh token and overwrite the old refresh token in the database, so that old refresh tokens can't be used to get new tokens?
How long should such refresh tokens live?
Yes, but all will usually mean "all in a given time frame". The time frame will depend on your needs - for how long do you want to be able to identify any potential refresh token leaks.
You can, but then you don't get any better security than without using token rotation. This is because you never know who used the current token first - the legitimate user, or the malicious one, who stole your token. If it was the latter, then she will now have access to working access/refresh token pairs. The legitimate user will be left with an invalid token.
This depends on your requirements, features, security etc. You will usually find information that a refresh token should be valid for a couple of hours (usually up to 8), but I've setups with refresh tokens valid for days or even months.
We are using Azure AD authentication with a bootstrap MVC site.
Everything is fine and dandy - except we have an issue with the token timeout.
I have read multiple articles about the token lasting 1 hour before re-authenticating against Microsoft.
Our problem comes up when posting data.
Efter we enter a page with a post form on it - and this hours expires when on the page - the post data gets lost when posting the data. Everything points in the direction of the problem occurring when the site goes to get a fresh 1-hour token.
Has anyone here had experience with this or have any idea of how to get around this problem?
Not sure if this is the right way of doing things, but this is how we're handling this situation.
Basically when a user authenticates against Azure AD, you get 3 things back - Access Token (which expires after 60 minutes), Refresh Token and Token Expiry. What we do in our application is cache these three items.
Whenever we perform something that requires Access Token, we first check if the token has expired or not (by comparing the server date/time with the token expiry). If the token is not expired, we simply use that access token. However if the token is expired, we fetch new tokens using refresh token (fetching new tokens using refresh token will again return Access Token, Refresh Token and Token Expiry which we cache again in our application).
I followed this tutorial for using JWT token. The token expiry is set to only 5 minutes, but what if I wanted to invalidate the token after 1 minute of use? I want to be able to make an API call to /api/logout and that should delete my token.
I'm using Express and Node.
It seems like from what I could gather to do my option is to have a token db that stores the token. When I want to expire my token, I then expire/remove the token from the DB.
I've also seen people casually say "remove" the token from the physical hard space, but I cannot figure out where the token is physically stored for me to remove it.
The general benefit of a JWT token authentication is that the tokens can contain all the session information you would normally keep in your session store. This saves considerable resources, especially in request-to-response times, because you do not have to look up session data on each and every request - the client gives you all that.
However, it comes at the cost of not being able to revoke a JWT token at a time of your choosing, because you lost track of state.
The obvious solution of keeping a list of invalidated tokens somewhere in your database kind of removes the above-described benefit because you again have to consult the database on every request.
A better option would be to issue short-lived JWT tokens, i.e. tokens valid only one minute. For a web application, an average user may perform several requests in a minute (a user navigating around your app). You can give each user a JWT token that will last a minute and when a request with expired token arrives, you simply issue them a new one.
Update: Issuing a new access token after presenting an expired token is a very bad idea - you should treat an expired token as invalid, as if it has been forged. Better approach is to have the client present a refresh token which will prove the user's identity, and only then issue new access token. Note that verifying a refresh token must be a stateful operation, ie. you must have a list of all valid refresh tokens per user somewhere in your database, because if the refresh token is compromised, the user must have a means of invalidating that token.
1) Simply remove the token from the client
2) Create a token blacklist
3) Just keep token expiry times short and rotate them often
Please have a look at Invalidating JSON Web Tokens
Invalidating JSON Web Tokens
I'm fairly new to token based authorization. I'm trying to find the flaws in a custom expiration/token-refresh scheme.
I have a basic JWT auth setup in an Express API; I'm setting the JWT expiration to 1 hr; However, JWT checks token expiration relative to the time the token was issued. I would prefer that the expiration time gets reset after each successful api call. If my user is actively using the app for more than an hour, I don't want them to have to log back in to refresh the token (and possibly lose whatever data they are working on.)
On the the other hand, I do want the token to expire if they are not responsive for more than an hour.
I have come up with the following approach:
During every successful API request, issue a new JWT and send it in a
custom response header. My client side code is responsible for
checking this JWT response header and using its value as the new default Authorization request header. Thus, if there is no API
request from the user for more than 1 hour, the token will expire and
not be refreshed. Login would then be required. In addition, the original issue-date of the token (timestamp of login-authentication) will be stored so that a "hard-expiration" of the token will be enforced after 24 hours.
This seems fairly straightforward and reasonably secure, but I haven't seen any reference to it in my JWT research. Is there a better way to achieve the same goal? Am I missing a major security hole with this approach?
UPDATE:
After thinking of this for some time, I realized that the problem with this is that it opens the door to replay attacks that could not be thwarted by token expiration. So there should absolutely be a "hard-expiration" check: hard expiration would invalidate the token at some time after issue date, regardless of recent user activity.
Here you can check my answer for this scenario:
implementing refresh-tokens with angular and express-jwt
What I have done is to have a time window where the server checks if the token expiration and the local server time is in this window and then send a response header with the refreshed token.
If you agree and realize that you need a hard expiry time anyhow, why not set the expiry time of the (one and only) access token to that and stick to plain OAuth 2.0? An asymptote of what you're doing now, would be to issue your own API specific token/cookie after first use of the access token (in the API response) and enforce subsequent API access based on that. That is a valid approach, but duplicates a lot of stock OAuth 2.0 Authorization Server functionality in your own API. I don't see a good reason to go there.
I have an app, that pulls data from my Instagram account.
I authorized this app once, and got access token. But I'm worried,
what if this token expires? Should I authorized the app each time the
token expires?
Can I receive another access token from the auth code?
If no, what can I do to have my app always pulling data from account
without my participation?
Thanks.
But I'm worried, what if this token expires?
AFAIK, Instagram accesstokens don't expire currently.
Note: From Instagram documents.
Note that we do not include an expiry time. Our access_tokens have no explicit expiry, though your app should handle the case that either the user revokes access or we expire the token after some period of time. In this case, your response’s meta will contain an “error_type=OAuthAccessTokenError”. In other words: do do not assume your access_token is valid forever.
Should I authorize the app each time the token expires?
At the moment, you do not need to do that, as token does not expire. As and when the token expires in future, a corresponding warning or error code and message will be sent to you, which you need to handle.
what can I do to have my app always pulling data from account without
my participation?
You can try following:
Use sharedpreference to store the accesstoken.
First time when you try to fetch data that needs accesstoken(Authenticated requests), first check in the sharedpreference whether the accesstoken is stored or not.
if yes then you don't need to login, just use that accesstoken. If you don't have the accesstoken in preference then do the login using instagram credentials, get the accesstoken and then share it in shared preference and use that for subsequent requests.
You can provide instagram logout option in which you just need to clear the accesstoken from sharedprefernce.
Hope this is helpful to you.
Update - This no longer works as mentioned in the comments
While not well documented, It's worth pointing out that retrieving a feed of posts does not require an accessToken.
https://api.instagram.com/v1/users/{user-id}/media/recent/?access_token=ACCESS-TOKEN
can also be called passing just your client_id
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id=CLIENT_ID
This isn't made clear in their documentation though.
https://instagram.com/developer/endpoints/users/
The Instagram access token expires at arbitrary times.
Twice in the in the last 7 months from my experience.
I did not find any way to regenerate the token without my participation, the only valid solution IMHO is to avoid the official API and use something like:
https://stackoverflow.com/a/33783840/
For the last 3 week, I have created new token multiple time and its expire after 2 days, but I also notice that some token didn't expired which were created before 3 years. Also, Instagram docs say the token can expire any time in the near future.
There is a hack at this moment to show the user's last post just append URL with `/?__a=1''
after user name such as
https://www.instagram.com/vaseem.ishak/?__a=1
you will get user last post with image text, no of comment like etc.just dig little the return JSON