• Talk about built in clients
• Guidelines for protecting keycloak client and admin endpoints.
• Document Published endpoints for server
• More detail explanation of Keycloak core concepts
• How to run on Amazon, Azure, etc.
• Using Keycloak capabilities within a Client Application
• Improved organization / grouping of REST endpoints.
• All terms used in the User Guide need to be defined. For example the guide often makes reference to "adapters" and there is even entire chapter devoted to different adapters. But nowhere is it defined what an adapter is, what it's purpose is, what role it plays, when and why is it needed, etc. The same is true for the term "client". I'd start by looking at the table of contents in the guide and make sure at a minimum every term that appears in the table of contents has both a definition along with an explanation of how that item fits into the overarching architecture of Keycloak. The use of these terms in the guide should hyperlink to it's definition. After the terms referenced in the table of contents is done each section/chapter should be examined for the use of undefined terms.
• The guide would really benefit from the addition of diagrams that illustrate the relationship between architectural components, data flow and how data is evaluated to yield a result. For example how is authorization performed? It starts with receiving an authentication request, it involves requested OAuth scope, client roles, realm roles, effective roles, etc. Where do each of these data items come from? What order are they processed in? What component is responsible, etc. Just being able to look at a diagram can provide extensive insight and can avoid having to answer questions later. For example suppose a user is not receiving the correct authorization, as an admin what data sources and configuration items do I need to check? A good diagram will answer these kind of questions.
• The use of the term authentication and authorization needs to be carefully checked. I noticed the OAuth2 spec seems to lack discipline with the use of authN and authZ. I find it very confusing when I see the wrong term used, authN and authZ are very distinct concepts.
• All CLI commands need matching man pages.
• Conditional OTP - There is no docs for this ATM
• Additional to the already mentioned architecural insights: how do things work together, how is the transaction model (e.g. to write correct user federations, etc)
• How do different flows for identity providers work and how does the configuration UI for these work (first broker flow, browser, etc), some sequence diagrams maybe?
• Explanation of role mappers (Blog and doc is mentioning these, but there is no doc, examples help everywhere)