[keycloak-user] Keycloak and rfc7523#section-2.1

[jim-keycloak at spudsoft.co.uk]

Hi,

I need Keycloak to support something equivalent to 
https://tools.ietf.org/html/rfc7523#section-2.1 (Using JWTs as 
Authorization Grants).

My use case is that we are an SAAS provider with a number of different 
products.
Where we have common functionality between different products we have a 
plugin UI (Angular) that is embedded within the host product and that 
talks to a dedicate REST endpoint (that is independent of the host product).
The plugin UI has to provide authorisation through to its REST endpoint, 
and that authorisation has to identify the specific state of the user (a 
client access token is not sufficient).

My intention is for the host product to ask KeyCloak for an assertion 
(creating a federated user on the fly), then give that assertion to the 
plugin UI, which will ask KeyCloak to exchange it for an access token.

The host product cannot directly request an access token because it will 
be a different client from the plugin UI (quite apart from it being 
'wrong' to pass an access token around) (the host product is a 
confidential client, the plugin UI is not).

In a general implemention of "Using JWTs as Authorization Grants" the 
assertion ought to generatable via any mechanism as long as KeyCloak is 
able to validate the signature.
For my usage it is important that the assertion contains information 
that the client (the plugin UI) cannot access, which would require 
support for JWEs in a general implementation.
By having the assertion generated by KeyCloak I am able to store 
information from the assertion request and not put that information into 
the assertion itself, getting around the need for JWEs.


So I've been doing some playing with SPIs in KeyCloak to see what I can 
achieve without requiring changes to the core.

I have a "GenerateAssertionResource" that is implemented using 
RealmResourceProvider.
This generates a token based on passed in arguments (after 
authenticating the client), and also stores a federated user.

I also have a BearerTokenUserStorageProvider that can validate passwords 
that contain assertions.

This setup works, I can satsify my use case, but it's not exactly RFC 
compliant.

To make this better, what I'd like to have is:

  * Suport for JWEs.
    At the moment the only Java JWE library that I've come across is
    Nimbus JOSE, but I suspect you consider that a competitor :)
    Support for JWEs would also enable opaque access tokens, which would
    be nice to see.
  * Support for a grant_type of
    urn:ietf:params:oauth:grant-type:jwt-bearer in TokenEndpoint.
    This would be easy to add as another hard coded grant type, though
    it might be nice to see an SPI used to validate grant_types enabling
    further extension in future.
  * Somehow the DirectGrant flow would need to support authenticators
    that are not based on passwords.
    It's easy to write another authenticator (that was my first approach
    to this problem) but the Direct Grant flow has Password as Required
    (and it's not possible to set Password as Alternative).
    I need to support password grants as well, so replacing the flow
    doesn't work for me.

This would still require the implementation of SPIs to actually use JWTs 
as Authorization Grants, but there are different approaches that they 
could take.
A generic implementation would have to be quite complex.

I'd be happy to produce a PR for the changes to TokenEndpoint and the 
Password authenticator if that would help.

Jim