Nope, if it something you really really really need it we could look at it. Or at least
consider for 1.1
I don't think we'd allow revoking individual refresh tokens, but instead allow
revoking a client from a specific user session. The end result would be pretty much the
same, except if there was multiple refresh tokens active for a client they would all be
invalidated.
The revoking part is easy, it to endpoints, admin console and account management that is
more time consuming :/
----- Original Message -----
From: "Bruno Oliveira" <bruno(a)abstractj.org>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Thursday, 17 July, 2014 2:25:34 PM
Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
Good morning Stian,
Is the revocation of the refresh token[1][2] also planned?
[1] -
http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html
[2] -
http://tools.ietf.org/html/rfc7009
On 2014-07-17, Stian Thorgersen wrote:
> As we didn't have enough things to do last minute I come up with more
> things which I think we should do for 1.0.final:
>
> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>
> This would be super simple to do, and would let us have a single
> persistence.xml for everything (testsuite, server, project-integrations).
> Everything worthy of configuring in persistence.xml (including datasource)
> can be passed in the Map overrides when creating the EntityManagerFactory.
>
>
> 2. Introduce server-dependencies-min and server-dependencies-all poms
>
> We have a few places that includes all the dependencies required (server,
> testsuite/integration and testsuite/) as well as other project such as
> AeroGear and LiveOak. Instead of everyone having to list all the
> dependencies they could have a single dependency on either
> server-dependencies-min or server-dependencies-all. Min would exclude most
> if not all provider implementations (such as PicketLink/LDAP, social
> providers, etc).
>
>
> 3. TOTP SPI
>
> At the moment we only support Google Authenticator, I don't think that's
> sufficient. We should at the very least add support for one more, and have
> an SPI so users can add their own. I think this would be related to the
> UserProvider sync work, as some UserProvider implementations may require
> both a password and totp to verify a users credentials, while others would
> only be able to verify the password and then have Keycloak verify the
> totp.
>
> Also, do we need to support users with more than one totp? Personally I
> have two for work (one I use daily and another for backup).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj