[keycloak-user] Backend to Backend Call

Stian Thorgersen sthorger at redhat.com
Fri Nov 4 01:34:37 EDT 2016


By passing the refresh token you are giving the service "unlimited" access,
which you probably don't want to do. Refresh tokens are really designed to
be kept securely by an application and not to be passed around.

Could you have the backend service use a service account? That way it can
obtain tokens on behalf of itself.

On 4 November 2016 at 00:08, Morse, Alexander (US - Newton) <
amorse at deloitte.com> wrote:

> 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 at redhat.com]
> *Sent:* Tuesday, November 1, 2016 5:14 AM
> *To:* Morse, Alexander (US - Newton) <amorse at deloitte.com>
> *Cc:* keycloak-user at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>


More information about the keycloak-user mailing list