1

Browsing the keycloak docs we spotted this statement:

You must provide a session authentication strategy bean which should be of type RegisterSessionAuthenticationStrategy for public or confidential applications and NullAuthenticatedSessionStrategy for bearer-only applications.

The last part (bearer only) makes sense to us, as the 'state' lives in the JWT token, however we do not understand why public/confidential clients require apps to manage state having in mind tokens are still provided by keycloak.

Could anybody help us understand why?

José Carlos
  • 414
  • 2
  • 8

1 Answers1

1

To answer your questions i propose to consider two approach:

  1. Bearer only + public. E.g. stateless backend + SPA application that will take part in standard flow: redirection to Keycloak on load and retrieving token pairs when login finished on Keycloak side. Frontend also responsible to refersh tokens.

  2. Old school monoliths like applications with JSP or something like that. In this case instead of retrieving access token from frontend request, token retrieved from internal Http session (which identified by application cookie like JSESSIONID). Tokens refreshing also performed by backend (Keycloak adapter will do all magic behind the scene)

I hope now its clear that even if SSO state is incapsulated inside tokens, token pair in turn also could be incapsulated in application state (like session scoped bean)

Btw confidential clients also could work as bearer-only client (you can disable "Standard flow" switch for them). This useful when your service has to make some calls to other services behalf itself, not behalf user. See "service account" documentation.

solveMe
  • 1,866
  • 1
  • 18
  • 20