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.
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.
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:
Introduction
I have my own user account database and am building an oauth2 authorization server to centralize authentication logic across my companies' websites using authorization code grant type.
Let's say I have deployed my authorization server's login page at https://auth.my.company.com, and deployed a website at https://my.website1.com. When a user click on the login button at https://my.website1.com, the typical oauth2 authroization code flow will be triggered as shown in the picture below.
To explain the picture:
The user access to https://my.website1.com which renders a login button.
The user is navigated to the centralized login page with url https://auth.my.company.com?client_id=mysite1&redirect_url=https://my.website1.com/oauth/callback
The user enters username and password and submit the login form.
After the authrization server validates the user credential, it redirects the user back the the redirect_url https://my.website1.com/oauth/callback?auth_code=abcd passing a parameter auth_code=abcd
The website backend server communicates with the authorization server using the input auth_code to authenticate the user, the authorization server returns an access token.
The website responses to the user that the login process is success.
The Problem
At https://my.website1.com, I would like that the user can also login with his/her Facebook account, which will be bound with the account in my user account database. I would like to centralized this process as well (i.e. so that my another site https://my.website2.com can reuse the same login process). So I am thinking of implementing a 2-hop oauth flow as in the following picture.
The user access to https://my.website1.com which renders a login button.
The user is navigated to my centralized Facebook login endpoint https://auth.my.company.com/facebook
The authorization resolves its Facebook client id and redirect url and then redirect the user to Facebook login page.
The user logins through Facebook.
Facebook redirects the user back to my authorization server, passing the authroization code.
My authorization server uses the authroization code from Facebook to authenticate the user with Facebook APIs
My authorization server redirects the user back to https://my.website1.com passing its own generated authorization code.
The website backend server communicates with the authorization server using the input auth_code to authenticate the user, the authorization server returns an access token.
The website responses to the user that the login process is success.
Question
I cannot find any reference to this kind of 2-hop oauth so I am afraid that I am doing it wrong. I would like to know if there are standard approch the handle the centralized social login like this.
Found a reference from IBM website that looks very similar to the flow in question. Here
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 will try to keep the question as clear and direct as possible.
Social authentication (Facebook) configured with Okta with redirect URI as URL to my custom webapp. This custom webapp relies on Okta for authentication.
User visits my custom webapp (unauthenticated) and clicks on the social authentication URL to login to my custom webapp.
User follows the normal flow, gets authenticated by facebook and thereby by Okta (as per usual flow) and is then redirected by Okta back to the custom webapp.
The entire flow is successful and the user can see an Okta session cookie set in their browser.
Custom webapp now needs to show the user their own profile by making an Okta API call.
Problem: How can my custom webapp identify who just logged in so that they can fetch their Okta profile using API?
I am aware that Okta knows who just logged in due to claims that facebook sends to the OAuth client (Okta), but how will my app know the identity of the user who logged in?
Thanks,
Jatin
It depends on the OAuth2 flow you've chosen for your app, but the end state is getting an id_token from Okta which contains claims about the user that just logged in.
If you've set response_type=code in your social auth url (/authorize), after Step 4 you'll get a code query param in the redirect that you can then exchange for the id_token using the /token endpoint.
Or, if you've set response_type=id_token, you should already have the id_token in the redirect - you just need to validate/decode it (more info here).