In my app, I allow my users to authenticate with their existing google, microsoft, etc accounts via OAuth2.
Everything runs smoothly. Upon getting callback to local redirect url, I successfully request and receive bearer token from endpoint. With access token in hand, I then request UserInfo from user info endpoint. I then compare email address in UserInfo JSON object with the email address registered in user record and if they match, I consider user signed in.
Now, my question is regarding bearer token and session timeouts.
Google bearer token looks like it authorizes for 60 minutes; while my server session lasts 30 minutes (I haven't changed the default).
Since user already got successfully authenticated, the session id will remain active and alive while there's activity within every 30 minutes. However the bearer token expiration will have expired after an hour.
I would normally assume that I need to refresh the access token before it expires so long as there's activity within the established server session. However, google does not appear to have a refresh token endpoint.
But even if it did, would it be desirable to do this?
Or since the fact that I have an active session id from an authenticated user is enough to allow access to protected resources while only the session id is 'alive'?
I'm assuming it is, since some websites allow customers to maintain their sessions for days at a time, at which time, bearer token would have expired long before.
And lastly, how long would you recommend I keep my users (customers, really) with an open session? My website is on online store.
Thanks to all!
Your session can be completely detached from Google's session. You should only be concerned whether your session is still active. The validity of the access token from Google is not relevant here. Remember that the expiration time of an access token has, in fact, nothing to do with a user's session at all. E.g. you log in a user using Google. The user authenticates at Google and you get an access token, which is valid for 60 minutes. The user then logs out at Google. Your access token will still be valid until that 60 minutes pass, even though the user logged out from Google, and her session is no longer valid there.
As for the length of the session, this is really up to you. If you know your customers are likely to come back often, and you want to make it easier for them you can even keep a session indefinitely. In such a scenario you should think about security and privacy - if the user leaves their account logged in on a shared computer, how much could it hurt them if someone else manages to use their session after a week or so. If you know your customers are likely to come back every few weeks or months to your store, then it really doesn't matter if you keep the session open for a day or five. Most of them will have to log in again anyway.
So to answer the question of the length of the session you should study the behavior of your users and take into account security and privacy issues.
Related
Do people typically store permissions in a JWT? I've seen example that might have admin: true or scopes: ['add_foo', 'delete_foo', 'read_foo']. And this seems fine, other that the potentially large size that the JWT could become if there are a lot of permissions/scopes. It seems like it would be really useful as you wouldn't need to hit a DB or cache to get the users permissions as long as the JWT can be verified.
My main question though is how these would be invalidated in the event of a permissions change.
For example, sys admin Joe, revokes the 'add_foo' and 'delete_foo' permissions from user Bob, but keeps the 'read_foo' permission. In this scenario user Bob should not have his token entirely invalidated and need to log back in, he should basically be forced to get a new JWT with the new permissions and carry on as normal.
I've seen examples explaining issuing a new JWT in the event of a password change, but the difference here is that sys admin Joe does the update to user Bob. Thus, there is no opportunity in this workflow for user Bob to get the new token immediately.
Most examples suggest for invalidation maintaining a black list of revoked tokens, or changing a DB record ID so the token is no longer valid, or having a per-user secret and changing that.
I see that all of these would work for the revoking of the token and test that its invalid, but how does the user then get a new token? their current JWT is now invalid? Trying to do anything with it should fail.
I've seen mention of a "refresh token". Are these widely use? Are they secure on the web or mainly used for mobile apps where the refresh token is harder to obtain. It seems like it would be reasonably easy to steal a refresh token via browser dev tools or similar and then someone would have access forever to that account until the unauthorized access was noticed and the refresh token revoked.
Maybe in this scenario forcing user Bob to re-authenticate is not such a big deal? Permissions probably don't change too often.
Thanks, Mike.
You can set expiration date (for Web app we are usually using 15 min - 30 min, for mobile 1 week). When you set Issued at claims parameter ("iat"). Then every time when you validate token you should check the token's "age". If it older than 5 min you load data from DB and create new token with current "iat" value.
When permissions change you should invalidate the issued tokens for this user. There are different techniques to use. See Invalidating client side JWT session
But consider that revoking tokens is not a recommended practice because you lose one of the main advantages of JWT: It does not require server storage.
The objective of Refresh tokens, as defined in Oauth2.0, is allow applications to obtain a new access token without re-authenticate
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires,
If the permissions do not change frequently it may be easier to re-authenticate user, and if they change much consider whether they really should be included in the token
What happend if someone sniff the network and catch my entire request from my REST with the token? This person could send again the same packet and Impact without any problem right? Of course he's not going to know from which user is that packet, but he could impact anyway right? is this possible? How can lead with this situation?
Thanks!
Matt.
What happend if someone sniff the network and catch my entire request from my REST with the token?
The JWT is the authentication token, so he could impersonate the user.
This person could send again the same packet and Impact without any problem right?
The same packet or any other because if has the authentication token. It is the same case as if the user had lost your username / password
Of course he's not going to know from which user is that packet, but he could impact anyway right?
Yes, he can know the user, it could know simply decoding the 'sub' field of the token. This field, as defined in RFC , identifies the principal that is the
subject of the JWT. The attacker could use your own api to obtain or modify any information to which it has access
is this possible? How can lead with this situation?
Mainly use HTTPS to avoid man-in-the-middle and keep the tokens private. Set also expiration and renew tokens periodically
Of course, the attacker can use the token and get the same access as the victim.
If you want to limit attacker's actions, you need to perform several conditions:
Set expire time of the token as small as possible(5 min, 30 min, nor months neither years).
Use refresh token to get a new token and update refresh token every time you update old token (and when user is logged in, no doubt)
Use https (oh yes!)
Do not store passwords, credit card numbers and any confidential informations in the token ( I'm shure, you know it :) )
What is a good expiration time for a JWT so that a user will never get logged out unless he cliks log out? Note that the node.js server could be up and running forever
This is not the right way to Do it.
Never make your jwt have too much expiration time. If your token is stolen then attacker will get the more access because this token never expires.
JWT is private key based matching. Until the secret is not changed your source is accessible by that key.
Use refresh_token instead. Which will have expire no expire time.
Use your refresh_token to get new access_token.
You can expire refresh_token based on device also.
I got the Access Token using Box Api but it is expiring in 1 hour.
What I want here is,
Either I need non expiring access token or get the access token by passing my Box User Id and Password to API.
If above things are possible let me know the way.
Thanks in advance..
You've got what is called a Bearer Token and a Refresh Token. The Bearer token is good for an hour, and the Refresh token is good for 60 days. The Refresh token can be traded in for another pair of tokens, which resets both clocks at the time you do the refresh.
Box doesn't have tokens that you can get via a username-password grant in OAuth2, because that inherently doesn't work for enterprise customers that need to do SSO through their ActiveDirectory / Okta / Ping / 2-factor / SecureID signin flows.
What you probably want is an SDK that handles the refreshing of the token for you. Most users won't ever have to logon a second time, unless they go on vacation for a few weeks. Box has already released several SDKs, all on github with open-source licenses. Most of them take care of refreshing the token for you automatically.
We've also added some enhancements recently (early 2014) to help multi-server implementations work more smoothly with the refresh-token flow, including allowing you to use the old refresh token to get the new token multiple times in a narrow time-window. That helps with both multi-threaded environments trying to get new tokens across a number of threads (or servers). It also helps with the case where you have a network interruption and you don't actually get the new token-pair back from your initial refresh call.
I have a simple facebook site feed on my website, it allows no interaction by visitors to my site. It is literally a set of json dumped to a userlist.
The issue I am having is that the access token expires every 1-2 hours and the feed dies...
I need to automate the refreshing of a token or get a non expiring token. What is the best route for me to take.
I want to ensure that security is as high as possible.
many thanks
You can get the extended token, red this : Extended Access Tokens
This token expires in 2 months so no need to refresh this again and again.
And if you want to offline access on behalf of this user, you can use this and refresh it before its getting expired.