Support for password grant types about lico HOT 1 OPEN

The use case "to get an access token for API usage" from a password should not be used. We should not encourage insecure usage in my opinion.

Having that said, Resource Owner Password Credentials flow is often enough requested - recently there was a similar discussion at authts/oidc-client-ts#747 (review) which is worth reading. We ended up merging support for it into a client library.

@micbar I think it would be no harm to add it if it is bound to additional security constraints. which for a start I would see something like this (configured via identifier-registration.yaml).

• requires a registered secure client (means client secret is set and not a dynamic client)
• flow must be explicitly enabled in the client registration (boolean flag)
• registered client application_type must be native
• registrered client must be trusted
• registered client must have a scope whitelist which is empty by default (means client gets no scopes)
• must have client registration configuration for the lico specific identity scopes
• can support request object based extra claims (ideally signed only and somehow validated with json schema or similar)

from lico.