|
Improvements to SSO docs:
Chat notes
Typically, customers won't implement both the OIDC and Bearer Token approaches, meaning the configuration should really only reflect one or the other for a use-case scenario.
The OIDC flow is for user login where there's an indirect flow to a login page. The Bearer Token is a programmatic flow which is more behind-the-scenes. See here for more details on that => https://www.rfc-editor.org/rfc/rfc6750.
It would also be useful to highlight the multiple clients of the same type (while in the OIDC use-case specifically).
Highlight the Authorization section a bit better and make sure that customers know defining the groups/roles doesn't implement them as that needs to be further defined from within the client section.
maybe move the mapping OIDC attributes to a section on the main page
defaultBaseUrl (config > server > defaultBaseUrl) – talk about this a bit more as it's within Magnolia and a newbie might miss out on the meaning of it.
Then I believe we should organize this doc page by use case, less by config:
OpenID Connect * mostly for editors to log into Magnolia, via indirect flow
Authorization
Direct programmatic access, via plain OAuth 2.0, also abusively known as JWT authentication (JWTs are also used in OIDC)
Using relative callback URLs (in theory more cross-environment, but defaultMagnoliaUrl must be still be set (inside the application/war file), so the benefit is slightly defeated)
Configuring multiple clients (incl. of the same type, with the .2 suffixes)
|