Ask Your Question

Refresh revoked token in horizon/keystone

asked 2015-02-26 05:29:51 -0500

garcianavalon gravatar image

updated 2015-03-03 08:30:24 -0500

I'm developing on top of Horizon and Keystone and I have come across the following behaviour:
If user A loses a grant (for example gets a role revoked in one project by user B) all his tokens are revoked. Therefor, if the user was logged in and performing some actions in Horizon suddenly he will be unable to do anything and get a red warning message, because his current token is invalid and every request returns 401 Unauthorized. The only way I've found for user A to get a new token is to log out and log in again, which is annoying, counterintutive (because no explanation is given to the user about what is happening) and feels like a random failure for the user (because he might not realize someone revoked him a role).

The question: Is there anyway to get a new token (refresh) for user A under-the-hood and with out him noticing (other than maybe a page refresh)? I wan't to avoid having the user type the password again but the current token got revoked so I can't use it to fetch a new one. I've been looking into it and seems that horizon caches the unscoped token in request.session['unscoped_token'].

Edit after Haneef's answer
As @Haneef Ali pointed out in his answer, I can reuse this token to get a new scoped token. The question now is how to force Horizon to do this. Maybe calling the login view again will do it automatically?

Thanks for any advice or help.

edit retag flag offensive close merge delete


Automatic rescoping of the unscoped token is not currently supported in horizon. If you wish to do this, you would have to modify the process_exception in particular.

david-lyle gravatar imagedavid-lyle ( 2015-03-25 13:58:12 -0500 )edit

3 answers

Sort by ยป oldest newest most voted

answered 2015-02-26 10:43:49 -0500

Yes, you can convert the unscoped token to scoped token.

If you are using v2, then check this . Basically instead of sending username/pwd , you will be sending unscoped token and tenant name to get a token scoped for the tenant. Similar concept exists in v3 too, just the request format is bit different

BTW horizon does that too. When you login you will be getting unscoped token, after that horizon will scope it to default tenant or some tenant

edit flag offensive delete link more


Thanks for your answer. From it I get the confirmation to part 1 of the question and understand that I can get reuse the unscoped token (in other words is not revoked like the others) I'll edit my question to show this clearly but I still haven't find a way to reuse this token

garcianavalon gravatar imagegarcianavalon ( 2015-03-03 08:24:59 -0500 )edit

btw, just to clarify, I know horizon does the unscoped to scoped token in the login process, my problem is to force this conversion again upon detecting the scoped token was revoked without having to login again (type the password)

garcianavalon gravatar imagegarcianavalon ( 2015-03-03 08:32:28 -0500 )edit

answered 2015-12-21 17:13:54 -0500

mnparthasarathy gravatar image

Did you find a solution to this problem? I am running into the same issue. Is there some logic behind why all the user's tokens are invalidated if the user gets legitimately removed from one project.

I have successfully created a new scoped token by invoking the switch project flow with the unscoped token but it made sense for that context as I was deleting a project. For my current context of removing user from one project, I would prefer not to do that.

edit flag offensive delete link more


I ended up just letting it be, its a nuisance but seems that it rarely happens in production so...

garcianavalon gravatar imagegarcianavalon ( 2016-01-14 07:55:10 -0500 )edit

answered 2015-10-30 10:37:34 -0500

Haneef Ali is correct in that you can get a scoped token from an unscoped token. You could do it by calling


Unfortunately, it won't work for you in this case, because the unscoped token is being invalidated along with the scoped tokens, at least with my version of keystone. See: /keystone/token/

As a result, trying this call just 401's on the call to Keystone. I've validated that this is the problem by revalidating the token (update the valid column back to 1 in the unscoped_token's record), and then calling authenticate, which then succeeds.

I think Keystone would need to be altered such that the unscoped tokens were not invalidated.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2015-02-26 05:29:51 -0500

Seen: 1,542 times

Last updated: Mar 03 '15