Thanks for the prompt response, Stian.
I don’t love the idea of creating signed JWTs outside of Keycloak as that introduces some
key management complexity etc. Is it an acceptable idea to pass the refresh token in a
cookie instead of a header?
Are there plans to provide support for this use case in future releases?
Thanks again,
Alex
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Tuesday, November 1, 2016 5:14 AM
To: Morse, Alexander (US - Newton) <amorse(a)deloitte.com>
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Backend to Backend Call
Actually this is not a use-case that we solve particularly well, but passing the refresh
token is not a great idea.
One option would be to increase the access token timeout, but that would have side effects
on all other use-cases. The best and most secure option would be to have a one-time token
that is passed to the asynchronous service. This is not something we have support for
directly though and it would most likely not involve the IdP (Keycloak server) at all, but
rather be a signed JWT issued by the caller that can be used by the async service for the
callback.
On 31 October 2016 at 22:10, Morse, Alexander (US - Newton)
<amorse@deloitte.com<mailto:amorse@deloitte.com>> wrote:
Hi,
Want to know the recommended approach for having asynchronous backend services that are
secured through bearer tokens call each other. We have an interactive web application that
calls a backend service. The JavaScript adapter places the access token in the
Authorization header. This backend services starts an asynchronous job that then calls
another backend service, passing along the same Access Token. The problem arises when the
access token has expired while the first job was processing. Seems like one relatively
straight forward approach would be to have the front end pass a refresh token to the
backend, which it can use to obtain a new access token. Are there better approaches? The
adapters do not seem to natively support this.
Thanks,
Alex
This message (including any attachments) contains confidential information intended for a
specific individual and purpose, and is protected by law. If you are not the intended
recipient, you should delete this message and any disclosure, copying, or distribution of
this message, or the taking of any action based on it, by you is strictly prohibited.
v.E.1
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user