We have very specific requirement, where we are going to have 2 types of authentication mechanism,
username & password
username(authentication will be done in mobile app by putting pin)
We have login page build in react, which is calling keycloak login by keycloak admin client, with this approach we are not able to maintain session so try to use keycloak session management, but when we try to use keycloak, I don't find any option to use existing login page.
We need to use keycloak's login page and customize it as per our need, but even we do that keycloak always require password to login.
NOTE:
We have custom authenticator to handle condition for password login or mobile app login.
Related
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.
I would like to hide Keycloak's interface from my Customers.
Is it possible to login to Keycloak through an API (specially for Authorization Code grant type), so I can build a React component for example for my customers to login?
Is it possible to build my own Account app, that will interact with Keycloak through an API?
Only my staff should use Keycloak's interface to manage security.
You can redirect your application to the Keycloak login page, and change that login page to have the looks and feel that you desire using Keycloak Custom Themes. To communicate from your Account app to Keycloak Api you can use the Keycloak Admin API.
Yeah, almost every SPA (Angular, React, Vue, ...) developer dreams about replacing of IdP (Keycloak in your case) login screen (because default IdP login is ugly/it doesn't match app style/... and he can build cool login screen on the SPA level :-)).
Sure, it's possible. Switch to Direct Access Grants (Resource Owner Password Credentials Grant) and you can use that. But you will sacrifice security. Let's say you have Google IDP identity brokering, so users will be able to use also own Google account. Will you put your Google credentials to some custom login form, which claims that those credentials will be used only to login and they won't be stolen. I would say no, because app will see your credentials. That is purpose of IdP (OIDC or SAML protocol). It provides user identity to any app (especially for 3rd party apps) without exposing user credentials - that is perfect case for Authorization Code grant type.
So I would say it's possible to use own SPA login form, but it is wrong idea. I would use local app auth in you case.
Second question: you can build own Account based on Account REST API. It is pretty new, so there is no good doc for that and it's only available as an preview feature. New account console should use it - https://www.keycloak.org/2020/09/new-account-console.adoc.html, so you can watch network browser console to see API requests.
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:
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 have four custom apps (that are SPs), using Auth0 or OneLogin as my IdP. In Auth0 I create a connector for each application. When I login to one application and then open the other application, I get redirected to Auth0 to login again.
Is it possible to log the user into my IdP (or Auth0/OneLogin) automatically on that second app without having to click the login button on Auth0, since they've already authenticated with Auth0?
There is an unfortunate need to embed the second app into the first app and it's a poor UX to have the user login to the first app and then login again in the iFrame.
Auth0 Dev here, Yes this is supported Out of the box in Auth0, for this to work you'd have to turn Use Auth0 as IdP "ON" in your Client. When doing this Auth0 will then remember the client for 10 hours upto 3 days if the client is active.
The flow in your scenario will be
User logs in to any of the application.
User visits the other application.
The other application sees no session.
The other application redirects to /authorize endpoint.
Auth0 notices the session and redirects it back to your application immediately.
This is further detailed and explained at https://auth0.com/docs/sso
SSO is not having to re-enter credentials again but you only get SSO once you redirect to the IDP and you authenticate under the hood i.e. seamlessly.
So you still have to do something to trigger the redirect.
You could programmatically redirect to a dummy page that requires authentication that then redirects via your client stack e.g. OWIN OIDC.
Also, there is no standard for the cookies so you don't get SSO across multiple IDP unless they are federated together.
So if no federation and you login to Auth0, you will still have to login to OneLogin.