[keycloak-user] different properties for internal and external tokens

[Stian Thorgersen]

We don't have any immediate plans to add support for this, but it is a
fully valid use-case and a common one as well. I think there's two parts to
this one:

* Ability to exchange tokens - what you are suggesting seems the way to go,
but I haven't looked if there are alternative approaches
* Ability to have different token timeouts

Feel free to create a JIRA feature request and we'll look into it when we
can, but if you or someone else are able to contribute something that would
be even better.

On 11 January 2017 at 14:31, Waller, Tobias <tobias.waller at capgemini.com>
wrote:

> Hi.
>
> We are currently looking into creating a microservice based application
> and using Keycloak as identity provider. The application will consist of
> several services which will communicate in a stateless fashion. Tokens will
> be passed along the call chain (several hops) and evaluated by each service
> in order to restrict access (bearer-only services). In some cases calls are
> queued together with the token. So the processes are processed
> asynchronously and can take quite some time. But they are guaranteed to be
> processed within a determinable period of time (e.g. 7 days).
>
> Processes are triggered in three different ways:
> 1. by internal (batch) processes (via client credentials grant)
> 2. by external legacy applications (via resource owner password
> credentials grant)
> 3. by external users via web interface (via implicit grant)
>
> Tokens issued for use case 1 and 2 are held strictly within our datacenter
> (internal token). Therefore we see no harm in issuing tokens with a
> sufficient lifespan (e.g. 7days). Tokens issued for use case 3 on the other
> hand are passed to the browser of the user (external token). In order to
> avoid potential security breaches and information leakage we want these
> tokens to fulfill the following properties:
> a. have a shorter lifespan
> b. do not contain information not needed by the client. Especially, the
> token should not contain any roles specific to internal backend-services,
> which could be used to infer information about application architecture.
>
> Our first idea was to allow the user to trigger long running processes was
> to validate the external token in the api-gateway and exchange the external
> for an internal token. That is using the external token as authorization
> grant as described by section 2.1 of RFC7523. While Keycloak supports
> client authentication via jwt which is also described within the same rfc,
> this does not seem to be supported right now.
>
> Are there any plans to support the grant_type "urn:ietf:params:oauth:grant-type:jwt-bearer"
> in the future? How can we implement different properties for internal and
> external tokens without losing the identity of the user initiating a
> process or using distributed or sticky sessions with means currently
> available.
>
> Thank you
> Tobias
>
>
> ________________________________
>
> Firma: Capgemini Deutschland GmbH
> Aufsichtsratsvorsitzender: Antonio Schnieder • Geschäftsführer: Dr.
> Michael Schulte (Sprecher) • Jost Förster • Dr. Peter Lempp • Dr. Volkmar
> Varnhagen
>
> Amtsgericht Berlin-Charlottenburg, HRB 98814
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user