Shorter and cleaner IDs

[Stian Thorgersen]

Keycloak currently uses UUID as the IDs for most things, including users, clients, etc.

An UUID in string format is 36 characters long and looks something like:

30351eaa-1566-4443-ae26-5c136068696c 

Problem with an UUID is that it is relatively long, and is not very user friendly (can't be copy/pasted easily as double clicking on a UUID only selects a part).

If we Base62 encode UUIDs they become shorter as well as more user friendly. They'll then be 22 characters, looking something like:

1SxuGRb4LqqYQI6hD0jU56

Base62 encoding is quite nice here as it only contains characters A-Z, a-z and 0-9, making these nice and friendly to users. Another nice thing is that it is possible to decode it again to get the UUID representation again.

Same approach can be used to create more friendly secrets.

I did a quick prototype of this here:

https://github.com/keycloak/keycloak/pull/7804

Keycloak seems to work just fine with this change, but there's a number of testsuite failures (as we have some asserts that check if an ID is in the UUID format, mostly just to check that it was initialized).

In the new map store prototype there's also some hardcoded assumptions that an ID is an UUID, which I don't understand the reasoning behind, and will be a breaking change anyways as we have a number of places where the ID can be supplied by the user rather than generated.

What do folks think is this a good idea or not? 

[Ingo Bauersachs]

For secrets/nonces or other volatile data I think the change to base62 is fine and one could argue if it should even be based on a UUID and not from SecureRandom. For persistent IDs, I’d stick with UUID, and preferably in binary instead of string form as long as possible. While not currently done so, a UUID can be stored as binary in databases as well (MSSQL: uniqueidentifier, Postgres: UUID) and would be much more efficient than either of the current string encodings.

 

We currently store the IDs of Keycloak groups in our system, assuming they are regular UUIDs. While this assumption might be invalid, I would assume that lots of other applications/integration use the same assumption (not just on group IDs) and would break badly.

 

--

Ingo

 

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAc%3DOPdop%3DFM%3DLgpYcVernDG-cpQjyX8dh0kVpSxwb8tJg%40mail.gmail.com.

[Julien.Pliss...@cdiscount.com]

On Thu, 2021-02-25 at 11:01 +0100, Stian Thorgersen wrote:
> What do folks think is this a good idea or not?

Mostly not a good idea IMO. It could be an improvement for client
secrets, but otherwise those technical IDs are not supposed to be
handled directly by end-users or developers.

In the rare cases where such an ID would have to be spelled out (e.g.
for checking) UUIDs are more robust: already split in reasonably short
chunks, no risks confusing lowercase/uppercase letters and I/1/l or
0/O.

The problem lies more on the side of selection algorithms than our
technical ID format.

On the other hand these technical IDs have to be script, automation and
interoperability friendly. UUIDs are an established standard and
implemented about anywhere while base62 is new, not standardized yet,
and not likely to be widely implemented anytime soon.

And also, moving away from UUIDs would really break our plans at my
workplace ;)

--
Julien Plissonneau Duquène

[Stian Thorgersen]

On Thu, 25 Feb 2021 at 11:31, Ingo Bauersachs <ingo.ba...@xovis.com> wrote:

For secrets/nonces or other volatile data I think the change to base62 is fine and one could argue if it should even be based on a UUID and not from SecureRandom. For persistent IDs, I’d stick with UUID, and preferably in binary instead of string form as long as possible. While not currently done so, a UUID can be stored as binary in databases as well (MSSQL: uniqueidentifier, Postgres: UUID) and would be much more efficient than either of the current string encodings.

I agree that secrets should be from SecureRandom as these for sure don't need to be a UUID. I had this change here:

https://github.com/keycloak/keycloak/pull/7804/files#diff-787a7c89d48087673ad3a152c8e7c9bbf1d1561f4d7c7dd823538adc81ca7f3e

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/VI1PR0102MB3104C7B9F7A8897A40BBC292E49E9%40VI1PR0102MB3104.eurprd01.prod.exchangelabs.com.

[Stian Thorgersen]

I need the shorter IDs for a different purpose (personal access tokens, will share more on that soon), so thought maybe it would be nice to use for other things as well, but I'm convinced now that wasn't a good idea.

Will update my PR to remove the change to IDs, but leave the change for secrets as I think that's a good change.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/dbecd0325e88bb967556bbc9c50f461c6e581662.camel%40cdiscount.com.