According to the Documentation on getA12 (GetA12 Login), UAA uses the “silent renew” with an invisible iFrame to refresh the OpenID Connect id_token. This basically triggers a new authentication flow before the token expires. Authentication is done by cookies of the Authentication Server (at least Keycloak does it that way).
This approach is kind of hard to configure, because you have to keep different thinks in mind. Especially when the authentication server is on a different domain that you BAP client, you need to make sure that the Browser can embed the iFrame (Content Security Policies, etc.)
There are certain edge cases where I was unable to get the token renew to wok at all, because browsers are picky these days, to whom they send cookies.
The OAUTH2 standard defines an alternative way on how to keep your id_token and access_token up-to-date: Using the according api endpoint with a refresh token (see for example here: What Are Refresh Tokens and How to Use Them Securely). Using refresh token of course has its own drawback.
Does UAA currently support token renewal using refresh tokens? Are there any plans to do so in the future? What are your thoughts on this topic?
in OIDC, in case you’re working with browser the PKCE is the best practise to use it due to security reasons. Refresh Token is not safe when you have browser interaction. The silend_renew with iFrame is documented in specification of OIDC you can see it here …. Therefore from UAA point of view, we don’t have any plan to support using Refresh Token to renew token. We also encourage people to really turn off returning Refresh Token from their IDP so they it’s not transfered to the browser and it’s redundant valid information should not be exposed.
On the other hand, Refresh Token is one of the option when we are talking about server-server communication (eg: server side rendering JSP page or JSF) with this it’s safe to use Refresh Token for renew token since it’ backend and well protected.
https://tools.ietf.org/id/draft-ietf-oauth-security-topics-12.html#rfc.section.4.5
I see your point.
It would be great to have some up-to-date, running-out-of-the-box example on how to set up UAA in the BAP client to work with an OIDC Identity Provider such as Keycloak. The corresponding Keycloak configuration would also be great.
Right now I have the feeling that each project is going through the same pain again and again to set this up correctly.
Hi @eduard-polar-knoll,
such an example will be provided with the Fullstack Project Template. The goal is to provide a production ready Project Template, for which the first step is to integrate Keycloak. This is currently in progress, as far as I am aware.