We are looking to implement OIDC for our mobile application following industry standards. For the most part we deal with stateless REST calls to the backend. For this the mobile application obtains tokens via Authorization code flow (public client, PKCE). During authentication, the mobile browser can show the appropriate login screens and will eventuelly forward to the intent of the app. Bearer tokens are added to every REST request to the backend. Refresh tokens work. So far so good
A small part of our application however consists of a stateful application, for which we spin up a browser. The stateful application is currently secured by the KeyCloak Tomcat Adapter (we will replace this later to something similar). This means that tokens live server-side in the session [or cookie] of the user.
Now we would like to offer the user a solution where they do not have to re-authenticate again when opening the stateful web application from the mobile app. Although I am sure more applications are dealing with this kind of challenge, we cannot find an out of the box solution for it.
We have considered a few directions;
- Token Exchange, where the mobile app gets a new token pair, which is included in the first request to the stateful web application, where the tokens are stored in the session. A few issues that we see with this;
- Main concern is the fact that the token pair is included in the initial GET request that is passed to the browser. This seems bad security practice.
- It requires code on Tomcat Adapter server side to receive the tokens. But AFAIK there is no SPI for this.
- One-time-token (Action Token) approach. This one we actually implemented using a RealmResource that can generate an ActionToken when called with a Bearer token from the app. The ActionToken can be marked as one-time-use, and it can authenticate the session on the stateful web application by (first) calling the ActionToken endpoint on KeyCloak. We actually implemented this approach but it doesn’t seem to fit nicely.
- The concept of ActionToken seems to be linked closely to an authentication session, where the user is in an authentication flow. But in our case, there is no authentication context (yet).
- When the AuthenticationSession is created in the ActionTokenHandler, it seems to close down the already existing KeyCloak user session in that browser. This existing session happens to be linked to the access/refresh token held by the mobile application. Result is that after handling the ActionToken, the next refresh from the Mobile device fails.
- A detail of this implementation is that when we redirect from the authenticated KeyCloak session to the WebServer, the OIDC provider in KeyCloak adds a OIDC response, which confuses the KeyCloak Adapter on Tomcat. This is because it is kind of ‘idp initiated’ instead of the normal OIDC ‘sp initiated’.
Are we on the right track here? Is ActionToken the way to go or are we missing some concept that might be a solution for our issue(s)? How do others in a similar situation handle this?
Any help is appreciated,