In the Curity Identity Server, how can I determine how long ago a refresh token was issued? I have a custom refresh token procedure that checks context.presentedToken.issuedAt but this is always now, not when the refresh token was issued. Is this a bug or how am I supposed to do this?
The issued at (issuedAt) claim of the presented token should tell you when it was issued; however, in versions up to and including 5.4.0, there was a bug that always set the presented token's issued at claim to be the current time (i.e., the time of refresh). It's easy to work around this though using the not-before (notBefore) claim. If you're running a build newer than 5.4, you can use issuedAt on the context's presentedToken object instead; both have the same value though, so there's no problem with upgrading if you were using not-before and haven't done anything special to that during issuance.
(Somewhat related, you can also get the time since the original delegation was issued. The following snipped shows this also.)
Just add this to your procedure and it should work with any version of Curity:
var now = new Date() / 1000;
var secondsSinceOriginalIssuance = now - context.presentedToken.delegation.data.created;
var secondsSinceLastRefresh = now - context.presentedToken.notBefore;
Related
I want to invalidate refresh jwt token without maintaining a blacklist of used refresh tokens with rotations, for this I had the idea of including a ValidationCode in the payload of the RT that the server generates and store whenever 2 refresh tokens are detected being in use with different rotation number (As an example RT2 that the normal user got from his last request and RT3 that the malicious user generated after sending a malicious request using the old RT2).
Once the server finds that a RT2 is in use while the latest one is RT3. The server should "Invalidate" the previous tokens, and issue a new RT when the user reconnects using his password etc. The process of invalidating token is simply changing the ValidationCode in the newly generated token, and accepts any request in which the token is valid + the validation code in the payload matches the one stored in the server for that user.
If Using this approach, if the malicious user try to use RT3 again, even if the jwt token is valid, the ValidationCode now changed and it will not match the one in the server however the newly generated tokens will.
Is this approach secure and good enough to replace blacklisting old tokens? which I think defies the purpose of using jwt at first + wasting time and memory storing the list and querying in the database
What you're describing here is a solution where you can just keep the latest RT used by the user in the database and allow only refresh requests with the RT saved in the DB. This is a valid approach but it has one drawback: you can have only one active pair of AT/RT for the user. If that is OK for you then you can go with this solution.
wasting time and memory storing the list and querying in the database
Either way you will have to query the database, so that doesn't change much. What you gain is a bit of storage space.
I'm using the Dailymotion API which uses Oauth2, their client tokens expire in 36000 seconds (10 hours), so I thought of creating new tokens for every call with the refresh token URL provided. Also, I didn't find any warnings in the documentation preventing me from doing this, is this a bad practice?
creating a new token on every requests is not the best way to proceed.
During your request, you can check (ex: with a "try") if your access token has expired then request new one with your given refresh token only if necessary.
If you are using a language like PHP, Python, Javascript, ... you can save much time using the available SDKs that already implement these mechanisms.
cf. https://developer.dailymotion.com/tools/sdks/
Yes, it is a bad practice, even though it's feasible. Authorization Servers might impose rate limiting on your client so that at some point you won't be able to refresh the token.
The access token must have expiration time for security reasons. If anyone manages to get hold of that token they will be able to use it only for the specified time. Good practice is to have as short expiration times as possible - e.g. 5 or 15 minutes. The 10 hours used by Dailymotion is a bit much, in my opinion, but it's their decision.
Refresh tokens should be kept securely by your client and you usually need a client secret to make a refresh request. This means that generally it's much harder for an attacker to get hold of a refresh token (or use it once they manage to steal it).
I use Spring-Lemon library for my spring boot project. I use a web front-end to my application. My question is, how to know if my auth token is about to expire? Documentation said a Get context operation should be used in this case to get a new token. But I did't find the way to find out when I should use this method to get a new token. Is there way to add the expiration date or the time remained to the responses, so my front-end would know that it should renew the token?
Knowing when it'll expire shouldn't be a problem, because you actually control it:
By default, the expiration will be 10 days after you call
/context (See LemonProperties)
You can change it by setting a
property
You override the property be calling get-context with a
parameter: /context?expirationMillis=123456
We are:
Using OAuth for both authorization and authentication
Using the implicit-grant flow (i.e. client-side flow)
Issuing relatively short-lived access tokens (measured in hours, not weeks)
I want to offer a comparable experience to the traditional expiring-cookie policy, where you get a certain amount of time that your credentials will work, but if you stay active on the site that window continually resets. I'm realizing that this is not straightforward in OAuth. Yes, tokens are issued with an expiry time, but most implementations keep that time fixed regardless of activity.
This isn't so weird when issuing extremely long-lived tokens as one does when authorizing an integration (like, say, a Twitter app). But it's weird when using OAuth for user-facing authentication. If we issue a short-lived token and the user goes for a big session on our site, their access may run out abruptly even though they are in the middle of something. Even if we issued a token valid for 24 hours, if the user comes back 23.75 hours later, they're going to get 15 good minutes and then suddenly get kicked off.
I'm trying to figure out how to offer my users a better experience while sticking to OAuth mechanics. So far, my best idea is to change the server-side implementation to update the expiry date on the token on each authenticated request (this only works because our tokens have a server-side component - I don't know how it could work if we went the self-contained token route). And then, to keep the client appraised of the updated expiry time, we'll want to send that back with our response, maybe in a header, or a meta attribute in the JSON object.
This approach seems a little complicated, but workable. Is there a better way? Has anyone else dealt with this issue? Am I nuts for even trying?
After finishing a WCF SOAP webservice which employs DotNetOpenAuth, it occured to me that once a consumertoken is stored in the OAuthConsumer table it is never deleted, not even after the token is considered expired.
I have edited the DotNetOpenAuth project's standard AuthorizedConsumers.aspx page so that users can manually revoke access to an application, basically deleting the consumertoken from the database, but I was wondering if it shouldn't be possible to have old tokens removed automatically. For example, when the user attempts to access the application which the token grants access to, shouldn't there be some sort of check to see if there isn't already a token, and if there is, whether it's expired or not, removing the old token if it is expired, before making a new one?
I don't actually know if there are any checks already in place (I did look for them but can't find them), are there? And how would I go about adding code to remove expired tokens from the database? Where exactly would I insert that code? In the StoreNewRequestToken method of the DataBaseTokenManager class?
Thank you!
Cleaning your database tables is beyond the scope of DotNetOpenAuth. You can implement it however you like. For instance, you might have a database stored procedure that removes token rows that have expired and invoke it on a timer somehow. DotNetOpenAuth expects you to only return valid (non-expired) tokens from your implementation of a token manager interface. The expiration of these tokens is given to you when DNOA first asks you to store them.
As for avoiding your tokens table growing too large, there are a couple of approaches. You can use short-lived tokens and be sure to clean your tables periodically. But the best approach is used in DotNetOpenAuth's OAuth 2 implementation, so if you can switch to OAuth 2 then that's ideal. Once you're there, you'll discover there is no token table at all. The closest thing you have is an Authorizations table, which only has a row for every individual user approval gesture, and you can remove them when (and if) those authorizations ever expire. With that authorization, clients can obtain as many unique tokens as they want and your database never grows because the tokens are self describing and signed. And DNOA manages it all for you.