Say I generated an authentication token on rackspace, and use it for a session login.
Now, for security reason I want to invalidate/revoke that token before the expiry date manually, so that on each new session of the application I have a new token to be safe.
Note: There is only one session at any given time.
I read the rackspace API docs. And it says that: the token's default lifespan is 24 hours. But that is too long. Can I set the expiration time manually?
The doc page at: http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/Authentication-d1e647.html
says that: A token may be manually revoked before the time identified by the expires attribute. So I started searching more but no luck.
There was this question on setting the expiration time manually for the token
https://community.rackspace.com/developers/f/7/t/669
and it say that there is no way to set it manually now.
I think revoking the token is possible currently, but I can't find any way for it, I just wanted to make sure I didn't miss something in the docs.
You should be able to revoke a token by sending a DELETE call to the identity endpoint: https://identity.api.rackspacecloud.com/v2.0/tokens/{tokenId}. It's documented in the identity service guide:
http://docs.rackspace.com/auth/api/v2.0/auth-client-devguide/content/DELETE_revokeToken_v2.0_tokens__tokenId__Token_Calls.html
Related
I'm using Cloud Firestore for Firebase to store informations about a Rest API Service written in NodeJs.
So, every request to Node will ask to Firebase informations about the service and, for first, it will authorize the request.
I thought that use an user generated JWT will be the best solution because the client have to simply include the JWT in his requests to authorize itself.
A Firebase JWT is related to the uid of the user that generates it.
Obviously, there'll be a control panel where the user can log in with email/pw and generate the JWT, and then the JWT will be included in his client system, for example like simple APIs that requires an API Key to identify the user and to work.
So, the idea appears to work good but i noticed that the Firebase JWTs expire in only 1 hour!
The user have to log-in to the control panel every hour to re-generate the JWT. That's not so friendly.
How can avoid this problem? How can i make the JWT expires in more than only 1 hour?
According to documentation:
The maximum lifetime of a token is 24 hours + skew.
[...]
with a skew of up to 10 minutes.
That means you cannot use these tokens forever, which kind of makes sense.
I looked at custom tokens and found:
The time, in seconds since the UNIX epoch, at which the token expires. It can be a maximum of 3600 seconds later than the iat.
Note: this only controls the time when the custom token itself expires. But once you sign a user in using signInWithCustomToken(), they will remain signed in into the device until their session is invalidated or the user signs out.
Perhaps you can do something with the signInWithCustomToken() as once logged in it expires only when the user is invalidated or signs out, but I believe the best course of action would be to look for another approach.
I have recently started using json web tokens and I have a few unanswered questions
what would happen if a users token expires while they are online? would they be forced to log in again when they request the next protected route? and if so it feels like there has to be a way around this so that the user does not randomly get logged out
how would you log someone out before the jwts expiration date considering the client holds all the info
any clarification on those 2 questions would be appreciated
what would happen if a users token expires while they are online? would they be forced to log in again when they request the next protected route? and if so it feels like there has to be a way around this so that the user does not randomly get logged out
When you make a request in a webapp, you need to pull in the available token. So the answer is "what does your app do?". There are lots of things you can do, such as making the request with the invalid token, or no token at all. But obviously that's not really a good idea. The best strategy is to:
Before every API call needing a token, check if the current token is valid
If the token isn't valid ask your auth provider to get a new token. This is known as silent authentication. How the provider handles this is totally up to them, usually they have a HttpOnly cookie saved for a secure domain, and return a new JWT.
If the silent auth fails, then the provider will tell you to log the user in.
At this point the best course of action is to redirect to the user to the auth provider using the same "login strategy" they previously used, to get a new "session" and a new "token".
how would you log someone out before the jwts expiration date considering the client holds all the info
Logging out is completely separate from token expiration. Logging out from a user standpoint is:
Tell the auth provider to remove the HttpOnly secure cookie
Delete the JWT in the browser
Change the UI to display the user as no longer logged in.
But that doesn't expire the token. The token will always be valid until the exp date. If you want to also prevent that token being used as if it was valid, you must deny-list the token using your AuthZ IAM as a service. For instance, if you were using Authress to manage access control, a DELETE https://api.authress.io/v1/users/{userId}/tokens/{tokenId} would cause subsequent checks using that token to return Forbidden. However, I will stress, the token is still valid, but you've taken the step to mark it as Deny-listed.
would they be forced to log in again when they request the next protected route?
If there is no other information that associates the session with the logged-in user (for example, there aren't any cookies or other tokens the server can use), yes.
Yeah, it's not very user-friendly, and JWTs often have a short expiry time. A common solution to this issue is to provide a refresh token as well, which could be stored in a HttpOnly cookie:
A refresh token has 2 properties:
It can be used to make an API call (say, /refresh_token) to fetch a new JWT token before the previous JWT expires.
It can be safely persisted across sessions on the client!
This way, the client can always have a valid JWT at any one time; they won't have to log back in, or logout and then log back in.
how would you log someone out before the jwts expiration date considering the client holds all the info
You can implement logic on the server to somehow blacklist or ignore the JWT from a particular user until they log in again. For example, after parsing the JWT, you could check to see whether the server considers the token to still be usable or not. If not, return a 401 error.
Most of our clients are having no issues whatever with our system. We have an integrator key and our users do an initial link up for integration using OAuth on REST. We store the access/refresh tokens. Works fine. At some point down the road some clients seem to randomly hit this.
We are using OAuth with the REST API and always get a new access token using the client's refresh token if their access token is within 30 minutes of expiring.
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
Q: Can the refresh token expire such that they would get this?
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
If you get this error then you need to restart the oauth flow again.
A refresh token does expire at some point. When it expires is a policy issue. To achieve the longest possible refresh token lifetime, request scope extended in addition to signature.
Re:
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
A: I'm surprised that you're getting this specific error, but I haven't tried this for awhile. I'd think the error would have a different name.
Q: Can the refresh token expire such that they would get this?
A: Same answer as above re the specific error name. In any case, a refresh token can definitely expire. Requesting the extended scope should minimize this, but at some point an account may set a policy that will also expire extended scope refresh tokens. Bottom line: your app needs to be prepared to ask the user to go through the entire OAuth Auth Code Grant flow again.
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
A: Using the wrong base url for the user. Also, at some point there will be organizational controls that can force policies upon the org's accounts. (Organizations own and control accounts.)
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
I'm using custom authentication in Azure Mobile Services by generating a JWT (JSON Web Token) in a custom login API. Once a user has a JWT, it's valid until its encoded expiry time is reached.
Beyond explicitly checking the JWT token against a sessions table on every authenticated request, is there a way to invalidate the JWT token before its expiry time (as would happen when a user logs out) such that any subsequent request made with that token as a value in the X-ZUMO-AUTH header would never reach any table API or custom API scripts?
Not really. When a user logs out in the client the JWT it uses isn't really invalidated - it's just removed from the client's memory (see the code on the managed SDK, for example). The JWT validation is done by checking the its signature against the mobile service's master key, and unless this key is changed (which would invalidate all of your service's JWT tokens, which I don't think is what you want), the token will be valid until it's expired.
Since you're generating the JWTs yourself you can consider using a smaller expiration time which may help in your case.
You can also suggest this feature in the mobile service's feedback forum. There's one related feature suggestion which I created, you can also consider adding a comment to that and voting it up.
To support JWT invalidation (there are always reasons):
I ended up storing a unique string per user which I hash with a global common string, so I can invalidate a single user's token, or all tokens as required.
No. The only way to logout a user and invalidate a JWT token is to remove/delete it out of the session table. This is the way you are already doing.
Store the token in a blacklist database table/collection, along with its expiry date.
Load unexpired blacklisted tokens into memory (indexed) and check every request's token against it.
Set an interval to reload the blacklist intermittently (to remove expired tokens from memory).