1:28 a.m.
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