Is it possible to configure Keycloak to store the access-token/JWT as a Bearer Token instead of as a Cookie?

Question

My understanding (which may be incorrect) of Keycloak is that once an User has logged in and is authenticated, the access-token/JWT is then stored as a cookie in the browser (under the default name 'kc-access').

Is it possible to configure keycloak to instead store the access-token directly as a Bearer Token instead of in a cookie?

Asking as I wish to use Keycloak to secure a web application, however most resources I have read on Authentication usually talk about access-tokens stored as Bearer Tokens, rather than as cookies.

From the Keycloak documentation, I cannot see any mention of options to store the access-token as a Cookie OR Bearer Token - Am I misunderstanding how Keycloak is meant to be used for providing authentication for web applications?

Ceasar

Could you confirm please - once you log in, you get a cookie named 'kc-access' with a token in it? Does it contain access_token or refresh_token? I get two cookies instead (under my keycloak IP), named KC_RESTART and KEYCLOAK_IDENTITY, both contain some tokens but neither has access_token no refresh_token. – Bunkum

Answer 1

Keycloak is used as a Single-Sign-On (SSO) provider. As such, it is designed to be used with multiple components. It is designed to keep a session open on the user's browser with a cookie. This session is private to Keycloak. The authentication flow then provides your application with a token that authenticates the user. Your application will then usually set it's own cookie to establish a session for the user and avoid having them login on each page.

When you login with Keycloak, it keeps a session open with your browser by storing a cookie there. The length of this session and other factors are configurable in your realm settings.

When you use Keycloak to login to another app, such as your web app, you use OpenID Connect (or SAML) as a protocol to authenticate the user with a flow similar to the following:

1. The user's browser is redirected from your application to Keycloak,
2. which checks whether the user already has a session, requires them to login (and create a session) if they are not yet logged in on keycloak
3. Redirects the user back to your web app with a short lived code
4. Your application connects to keycloak to exchange the code against a token.
5. Your application reads the token to identify the user and possibly stores it if it needs to access third party resources as the user using OAuth2.
6. Your application creates a session cookie to keep the user authenticated.

Most of these steps should be handled by a library. Keycloak provides many OpenID adapters for popular frameworks and servers, such as Apache and Tomcat.

The session cookies can be any string so long as they are unique and private between the browser and your application. They identify the user from the browser across requests. The bearer token is generally used to authenticate or to connect to stateless services such as APIs.

You can find documentation about the OpenID protocol here: https://openid.net/connect/faq/ .

Leasehold