[keycloak-dev] Migration of old offline tokens
Marek Posolda
mposolda at redhat.com
Mon Jan 16 04:31:37 EST 2017
Yeah, the legacy provider seems to be cleaner solution, but indeed more
work :)
I will try to see if I have time to do it as I have some other JIRAs
related to LDAP and I would like to look at least to KEYCLOAK-2333 .
Marek
On 13/01/17 15:09, Stian Thorgersen wrote:
> Option 1 is OK.
>
> Another option could be to add a special legacy provider. It would be
> added during migration together with the rsa provider, but would have
> a null value for the kid. It would not have an option to make it the
> active key. This would mean new installations wouldn't be affected and
> the provider could be removed once all old offline tokens are
> migrated. We can also deprecate the provider later on.
>
> On 13 January 2017 at 11:45, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> We have a bug that offline tokens issued in the old release (eg.
> 1.9.8)
> don't work after migration into the new release and can't be
> successfully refreshed. JIRA is
> https://issues.jboss.org/browse/KEYCLOAK-4140
> <https://issues.jboss.org/browse/KEYCLOAK-4140> .
>
> Reason is, that old offline token don't have KID in the header, but
> currently we require KID to be present, so we can lookup correct
> key. I
> wonder about possible solutions:
>
> 1) If KID is not present in offline token, then just look for the
> realm
> active RSA key and use that one for the verification. This is
> easier and
> I've sent PR for it now
> https://github.com/keycloak/keycloak/pull/3752
> <https://github.com/keycloak/keycloak/pull/3752> .
> However there is one small limitation though, that if admin
> changes the
> active realm key, the old offline tokens won't work (even though
> the old
> publicKey is still valid, it is just not active). So seems that if
> we go
> with this one, we should add a note to the migration guide about this
> limitation?
>
> 2) Iterate over all realm RSA keys and try to verify token with any of
> them. This won't have the limitation above, but it's more complex
> though.
>
> IMO the limitation is acceptable, considering that it's just about
> backwards compatibility. So I would rather go with simpler 1. WDYT?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
More information about the keycloak-dev
mailing list