I have keycloak version 20 installed, and api request to authenticate with username and password via REST API. I want to add remember_me to the request body, so I can extend the users refresh token (if the user wants it). Is that possible? I don't want to extend the refresh token lifespan for all sessions.
The API call is to the URI
/realms/{realm}/protocol/openid-connect/token
I also enabled the remember me for the realm, and it is available if I authenticate in the browser.
I have keycloak version 20 installed, and api request to authenticate
with username and password via REST API. I want to add remember_me to the request body, so I can extend the users refresh token (if the user wants it). Is that possible?
I am afraid this is not possible with Direct Access Grant Flow
From the Keycloak documentation section about the Remember Me functionality:
A logged-in user closing their browser destroys their session, and
that user must log in again. You can set Keycloak to keep the user’s
login session open if that user clicks the Remember Me checkbox upon
login. This action turns the login cookie from a session-only cookie
to a persistence cookie.
In Keycloak this feature relies on the browser cookies to work. For example, if you login with a user in one browser and then try to access the same account in another browser you are forced to authenticate the user again. It only works in the same browser (if cookies are enabled) because it was there where the cookie was originally created. Consequently, out-of-the-box, I do not see how this would work with the Direct Access Grant flow.
Related
A React SPA sends registration details to a backend (including username and password). Besides other things, the backend creates a keycloak user via the REST admin API.
The user then still needs to go to the keycloak login page for authentication. Is it possible to skip this step and automatically log-in the user on registration via API?
I thought if maybe the backend can obtain a token and send it to the SPA. But I do not know how to initialize keycloak-js in this scenario.
You can register the user and, after a successful registration, call the login endpoint with the same credentials in order to receive the access token.
Update:
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?
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:
The user's browser is redirected from your application to Keycloak,
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
Redirects the user back to your web app with a short lived code
Your application connects to keycloak to exchange the code against a token.
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.
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/ .
Given an Identity Server 4, can we implement a Single SignOn being used by different applications with a single user authentication server?
If so, how can we do that? Any reference material available for the same?
In fact, there is nothing special you have to do to enable single sign-on. It's available by default, but not for all scenarios.
In order to make SSO work there is only one rule:
The user has to login on the IdentityServer website, because that's where the SSO cookie has to be placed.
SSO is not available for grant types that do not require the user to login on the IdentityServer website.
How it works:
A user visits webapp1, hits the login button and is redirected to the IdentityServer website in order to login. IdentityServer will scan for the SSO cookie but will not find it since this is the first time and the user isn't authenticated yet.
After succesful login, the SSO cookie is stored (on the IdentityServer website) and an authenticated user is returned to webapp1.
The user then visits webapp2. As long as the user is not required to authenticate the user will be an anonymous visitor.
Authentication is required when the user clicks on the login button or visits a secured page (e.g. secured by the [Authorize] attribute). That triggers the authentication flow which redirects the user to the IdentityServer website.
Again IdentityServer will scan for the SSO cookie, but this time it's found. Being already authenticated, the user isn't required to login again but is instead returned to the website as authenticated user.
Please note that the client can overrule the SSO cookie by setting the prompt=login parameter.
Also note that cookies are not cross-browser. Visiting webapp2 using a different browser will require the user to login again because the SSO cookie isn't available for this browser.
Yes you can, that is what IdentityServer4 is used for (SSO & Authentication).
There is documentation and some samples.
I'm using keycloak, but I don't understand how the verification of authentication is made after the user authenticate in the app.
For example I have an app secured with keycloak, when a user try to access it, he/she will be redirected to authentication page, then (I guess, and correct me If I'm wrong) the user will have a token that need to be send with every request.
On a complete system secured with Keycloak:
A user clicks from a public page to navigate to a protected area within the application. The link to this protected area is in your application settings in keycloak admin console.
The user will be redirected indeed to the Keycloak authentication page. After providing Username and password, Keycloak redirects the user back to your application again with a code that is valid to a very short period of time.
The application communicates this code to Keycloak along with the Application ID and the Application secret, then Keycloak replies with the Access token, ID token, and a Refresh token. your Application will need only one of these tokens to see which claims the user has, and according to the claims, the user will be granted or denied access to protected URL(s)
Authorization code/standard flow:
From your app you're redirected to Keycloak's login page.
You give your username and password to Keycloak, and if these are correct, you will get a redirection to your app, and get an authorization code.
Your app send this auth_code and its id and secret to keycloak, and keycloak give you a token.
There are two more flows: resource owner credentials, and client credentials.
Here is the scenario:
Web App (webapp) authentication uses OAuth Authorization Server SSO
by setting spring.oauth2.sso.* properties.
User authenticates and webapp now have user credentials and access_token. Application then uses this token to call certain microservices on the backend.
When token expires it will eventually get 403 Unathorized.
Since we dont have refresh token should we just force user to login again?
What if we want user to stay logged in longer then token's TTL?
Any thoughts?
If I understand your question correctly, absent having a refresh token, the user will need to login again as this is the only way to get a new access token without it.