I am using JWT to authenticate with the Box API because I do not want my users to have to explicitly log in with their credentials (as you have to with OAuth2).
My issue is that the User Access token is only valid for 60 seconds.
So, does that mean that each time I make a request to the Box API (e.g. - iterate through some folders to find a specific file) I need to request a new User Access Token to ensure that it is still valid?
From my understanding there are no refresh tokens with JWT, so it seems this is the only solution ?
60 seconds is a very short amount of time. I don't want to have to keep track of time of each request, so it seems the only other option is to have to re-create the token for each API request. This seems ridiculous.
My issue is that the User Access token is only valid for 60 seconds.
Box JWT access tokens are valid for roughly 60 minutes. When you get a JWT access token the expires_in property will tell you exactly how long the token is valid, in seconds. In the example below, the token will expire in 4169 seconds, or ~69 minutes.
{
"access_token": "mNr1FrCvOeWiGnwLL0OcTL0Lux5jbyBa",
"expires_in": 4169,
"restricted_to": [],
"token_type": "bearer"
}
I don't want to have to keep track of time of each request, so it seems the only other option is to have to re-create the token for each API request.
Instead of keeping track of the epxiration time, you can make API requests until you receive a 401 response, then get a new access token, and finally then retry the failed request(s). Both options require coding effort. Fortunately some of the SDKs will do it all for you.
Related
I’ve been spending hours and hours on this, this is the first time I am using JWT and would really need some of your thougts.
Right now I store my tokens in separate httpOnly cookies (my access token expires after 15 min and refresh token after 7 days).
I have read that the most secure way to store the tokens is actually using a cookie for the refresh token and in-memory (like in a variable) for the access token.
While I understand this is secure, I do not really understand how it would work in practice. Would it mean that we have to create a new access token with our refresh token on each request? Or is there a way we can make it valid and copied to new variables until it is expired?
I am using react and node btw.
I spent days reading about this too.
From what I gathered a solution would be something like this:
User logs in with login and password.
Server generates a refresh token long lived to be stored as an HttpOnly Cookie, preventing XSS attacks as it can not be accessed by Javascript.
Ideally some sort of blacklist can be used server-side to prevent re-use of refresh tokens that have not reached their expiry but have been replaced.
Generate an access token which can either be stored in localStorage or in-memory (in a variable). The access token has a short expiry life of a few minutes.
If stored in localStorage, the token will not disappear on a reload of the page/browser (F5). It will also be visible in the console/storage.
When using localStorage to check if user is authenticated, the code will try to read the token from localStorage, jwt_decode it and set a user variable with the data that is in the token.
As tokens are not encrypted, just base64, their values can be changed in the dev console. A page that is "role: admin" only will be rendered if the permission is changed. The API will be responsible to check for permissions and reject the request if the token has been tampered.
Afaik, if it is stored in a variable it is a little less visible, it also gets wiped when reloading the page/browser.
When using a variable, to avoid refreshing the access token on every request, we can use the Context API, by creating a Component with the authenticated user context that will wrap the App/Router and then on every page that needs to be protected import and use this context and redirect if needed.
When the access token is not valid anymore, because it has reached its expiry, or because it has been wiped, the API call will get rejected. Intercept this call then call the API refresh route to use the refresh token to generate a new access token.
I use axios with axios interceptor to intercept the failed request, call the refresh route, set the renewed access token, then retry the failed request. (needs to be a GET request to avoid CSRF errors apparently).
In addition (not in place of), a setTimeout can be used to automatically refresh the access token every X minutes to prevent letting it expire.
To log out, remove the cookie (eventually blacklist) and wipe the context / localStorage.
Using axios, axios.defaults.withCredentials = true; makes sure that the cookie is sent with the requests and { headers: { 'Authorization': `Bearer ${access_token}` } } makes sure the access "bearer" token is sent with the request. These can either be set as defaults for every request or per request hence these 2 syntaxes.
Github example with Flask and React
I'm beginning a Single Page Application, and I'm using JSON Web Tokens to Authenticate client side (JS Client with Server API).
In my app, user provides credentials (app auth, facebook, google) and then server checks for user existence and returns a token.
Client JS adds token to each request in order to use the Server API.
When token gets issued, it has an expiry time and a max refresh time. If a set a short expiration time for the token and a "good" max refresh time I get into having to know when to refresh tokens. Best approach I've found so far, is to check on client when the token is being expired (5 minutes before) and then issue a refresh request. Then I'd get a new token. This could be done till max refresh time is reached. Then, user should have to reauthenticate.
Another approach I've seen, is that on server, if token is nearly or has just expired, it gets auto-refreshed and returned to client (which has to detect token change and store it)
But... what is the difference between this and having a single token that is long lived?
Is having a short lived access token which can be renewed with a refresh token tons of times better than having a single long lived access token?
The primary reason to use a short-lived token is to defend against session hijacking, when an adversary, through one method or another, steals session credentials (in this case, the token) and acts maliciously in the victim's session. The shorter-lived the token, the less time the attacker has to carry out whatever malicious activity they have planned.
So this is a random question that I can't seem to see an answer to.
I'm using Token based auth in my application. When the login credentials are first sent to the system, a token is returned. That token is then required with each and every request afterwards. When the token expires, a refresh token is used to determine if a new one should be issued. All pretty basic stuff.
What I've noticed is that the token isn't returned to the client with each web call. As in, client sends a message to the server with the token, server sends a response, but doesn't include the token unless it has been refreshed. Now, obviously thanks to client-side storage the token is still available.
My question is whether or not it is a best practice to return the token with each and every response, even if it is unchanged. Or if this really isn't a big deal and I can just stop worrying about it.
Thanks in advance.
Generally no, the response should not contain the token as it's unnecessary at that point - the user has already been authenticated for that specific request and appropriate actions have been taken (either a 200 with data or 401 or whatever).
It is the responsibility of the client to know the token when making a request.
I have application that continuously running in background. The app uses UCWA REST api. After authentication I get OAuth token and some expiration time. Authentication docs say "The lifetime of a token is eight (8) hours for authenticated users. The client application should monitor the expiration time and refresh the token as required".
So, when is it required to refresh token? What expiration time should I have in reserve when starting refreshing token? 1, 10 or 60 minutes? What are OAuth best practices?
The response from ticket service will provide the user with the OAuth token, type of token, and an expiration value. This value is measured in seconds which means you can divide out minutes (60) or hours (3600) to get a value that you can expect requests to start failing with 401 Unauthorized. Monitoring is most useful when the application is using anonymous meeting join because the token expiration is much shorter, ~1 hour, and it is the only authentication mechanism to directly offer renewing a token.
This leads to two potential approaches:
If using anonymous meeting join
Check expiration value found in authentication response and start a timer less than the expected value (maybe 1-3 min less)
When timer expires refresh the OAuth token
If not using anonymous meeting join
Send requests until a 401 occurs
Check response headers for WWW-Authenticate and send another authentication request to get new token
Re-issue request with new token
It is better to wait for the 401 to come before taking action to refresh the token in a non-anonymous meeting join scenario.
I am a little confused about calculating the time until the access token expires.
I am using server authentication (http://developers.facebook.com/docs/authentication/server-side/).
When I get the authentication code from the Facebook's request to my redirect URL, I send an authentication request back to Facebook and I get the access token along with 'expires' parameters, lately I could see that the expires is a long value that represents the time in seconds until the token expires. For some reason I think it used to be time in miliseconds.
Can I assume that the expiration time is now + expires (in seconds) - it seems to me too long (about ~5109691 seconds) - does it make sense?
Thank you for your help.
Server authenticated access tokens are valid for two months.
The value you are receiving is correct.
Edit:
https://developers.facebook.com/roadmap/offline-access-removal/
Read the 'Server-side OAuth Developers' section.