I have my own Login page where user enters username/password.
This username/password are used to login through Keycloak Rest API.
http://localhost:8080/auth/realms/Demo/protocol/openid-connect/token
input - {username,password,grant_type,client_secret,client_id}
And in response i get access token.
Now i wish to enable Authenticator (Google Authenticator). I have enabled it from backend. Now if user wishes to login thorugh my application, my login page i need to get below details.
1.) Somehow i need to include QR Code that appears on keycloak login page post username/password validation to show on my login screen for the first time login once user enter username/password. So do we have any API which return Keycloak QR code image in response.
2.) Subsequent login i will have OTP field, so need a REST api to pass OTP along with username/password.
Please help with REST API if keycloak has any. Integrating through Javascript.
Similar flow as described in use case 1 here
Just want to use keycloak as a database, doing all operation for me, input will be my screen. I do want redirection of URL's while login in and yet should be standalone deployed.
I've managed to implement this through the rest API of Keycloak. To realize this, you need to extend Keycloak yourself with a SPI. To do this create your own Java project and extend org.keycloak.services.resource.RealmResourceProvider and org.keycloak.services.resource.RealmResourceProviderFactory. You can find more information in the official docs (https://www.keycloak.org/docs/latest/server_development/#_extensions), github examples and other stack overflow posts how to do this.
Once you got this up and running you can implement it like this:
#GET
#Path("your-end-point-to-fetch-the-qr")
#Produces({MediaType.APPLICATION_JSON})
public YourDtoWithSecretAndQr get2FASetup(#PathParam("username") final String username) {
final RealmModel realm = this.session.getContext().getRealm();
final UserModel user = this.session.users().getUserByUsername(username, realm);
final String totpSecret = HmacOTP.generateSecret(20);
final String totpSecretQrCode = TotpUtils.qrCode(totpSecret, realm, user);
return new YourDtoWithSecretAndQr(totpSecret, totpSecretQrCode);
}
#POST
#Path("your-end-point-to-setup-2fa")
#Consumes("application/json")
public void setup2FA(#PathParam("username") final String username, final YourDtoWithData dto) {
final RealmModel realm = this.session.getContext().getRealm();
final UserModel user = this.session.users().getUserByUsername(username, realm);
final OTPCredentialModel otpCredentialModel = OTPCredentialModel.createFromPolicy(realm, dto.getSecret(), dto.getDeviceName());
CredentialHelper.createOTPCredential(this.session, realm, user, dto.getInitialCode(), otpCredentialModel);
}
The secret received with the GET must be send back with the POST. The initial code is the one from your 2FA app (e.g. Google Authenticator). The QR code is a string which can be displayed in an img with src 'data:image/png;base64,' + qrCodeString;
I know this is an old question, but I've recently been looking at something similar, and so thought it would be potentially valuable to share what I have found for others who may be looking into this and wondered what the possibilities are.
TL;DR
You can only really use the existing Keycloak actions to do this or embed the user account management page found at https://{keycloak server URL}/auth/realms/{realm name}/account in an iframe. That's it, I'm afraid. In my opinion it is currently best to just assign actions directly to accounts or use the Credential Reset emails to assign actions; both of these can be done via the Admin API if desired:
Send Credential Reset email containing assigned actions:
https://www.keycloak.org/docs-api/11.0/rest-api/index.html#_executeactionsemail
Set actions directly on the account (include the actions in the requiredActions portion of the user JSON that you send in the body to the endpoint):
https://www.keycloak.org/docs-api/11.0/rest-api/index.html#_updateuser
Background is that as part of a project that I have been working on we wanted to see if we could have an integrated way for users to set up their initial password and OTP device when a new account has been created for them, since the default method of sending them an email from Keycloak using the "Credential Reset" functionality has the limitations that a) it doesn't provide a link to the application itself unless you override the theme, and if you have multiple instances of the application for different users you have no way of knowing which instance to provide the link for, so may have to end up including a list of them, and b) it often doesn't feel truly native to the application, even with changes to the theme. If you're sensible though, I'd suggest you stop and just use this functionality - please see the TL;DR section above for details.
So, in short there is NO API endpoint for receiving a QR code to set up an OTP device. There are two places, however, where the QR code can be retrieved from - the OTP device setup screen when you log in as a user who has had a "Configure OTP" action assigned to their account, and the user's own account management screen.
The first option of the Configure OTP action screen is a non-starter. It only shows up when you log in, and so by definition the user has to log in to Keycloak via the Keycloak login page in order to trigger the page to be displayed. At this point you're already on a Keycloak page instead of one of your app's pages, and so unless you can get very creative with changes to these Keycloak pages via a custom theme, tapping into this page isn't really an option.
The second option is more interesting, but far from ideal. Every user who has logged in has access to an account management page that can be found at https://{keycloak server URL}/auth/realms/{realm name}/account. This page allows you to do things like change your name, password, etc. and it also allows you to add an OTP device if you don't already have one, or delete any existing OTP devices associated with your account. This OTP device tab of the account management page can be reached directly via https://{keycloak server URL}/auth/realms/{realm name}/account/totp.
As I mentioned, there isn't an API that you can access to view the QR code that shows up on this page. The only way it is accessible is via the GET request to https://{keycloak server URL}/auth/realms/{realm name}/account/totp, which returns the HTML for the page I've already mentioned. Okay great, so can we scrape the QR code programmatically and then put it in our own page on our application? Err, no, not really. You see, whilst a lot of the Keycloak API endpoints rightly allow you to send a bearer token (e.g. access token) in the authorization header to access and endpoint, this page will not accept a bearer token as a means of authentication/authorization. Instead it uses a session cookie that is locked down to the Keycloak URL. This cookie is set when you log in to your application via the Keycloak login page, and so is available to this account management page when you navigate to it, having already logged in, and since the account management page uses the same server and domain name as the original Keycloak login page, it has access to the cookie and can let you in. This cookie cannot be sent by your application to e.g. your own REST API to then programmatically call the account management page and scrape the QR code, because your application doesn't have access to it for good security reasons. This might be something you can change in Keycloak somewhere, but if there is I would strongly recommend against changing it.
So if we can't scrape the page from our own server, can we do something on the front-end? Well, as mentioned, your application doesn't have access to the session cookie but if you make a request (e.g. using fetch or axios) in your front-end JavaScript to the account management page then that request will send the cookie along with it, so that could work right? Umm, well actually you will get hit with an error message in this scenario due to CORS. CORS is Cross-Origin-Resource-Sharing and in order to allow the Keycloak page to be accessed then you would have to open up the settings on the server to allow it to be accessed from your website's address. I've seen some articles that look at how you can open up your CORS settings on Keycloak if you wish but I'd be very nervous about doing this. I don't know enough about the internals of Keycloak and how it operates to comment on how much of a security risk this is, but I certainly wouldn't recommend it. There some information here (Keycloak angular No 'Access-Control-Allow-Origin' header is present) on changing the "Web Origins" setting of your application's Keycloak client, but this opens up your application to some serious potential abuse. There is also the MAJOR issue that even if you scraped the QR code, the device isn't actually added to the user's account (even though it appears in the authenticator app) until you enter a code into the page that the QR code is on and click Save. Since there isn't an API endpoint that you can use to complete this operation, I therefore don't think that this option is viable either. I've tried out whether or not you can use the token retrieval endpoint at https://{keycloak server URL}/auth/realms/{realm name}/protocol/openid-connect/token to see if making a request with your username/password/otp code will somehow "register" your device and complete the process, but although you can get a token this way, and it doesn't complain about the otp code, it doesn't actually take any notice of the code because as far as it's concerned the user's account doesn't have a device registered with it. So we have to use the form on the account management page in order to complete this registration process.
So the final way of possibly doing this is.... an iframe. Sorry, yeah it's rubbish but that's all your left with. You can have the iframe point at your account management page, and because the user is logged in then they will be able to see the contents from your application's page. You can use relative positioning, fixed width and height and remove scroll bars to ensure that you ONLY show the QR code and the fields for the one time code, device name, and the Save/Cancel buttons. This, sadly, seems to be the only option at the moment, and due to how nasty and unreliable iframes can be in general - they certainly don't feel native to your application, and you'll need to override your Keycloak theme to get the page in question to look more like your app - I'd recommend steering clear of this and using the standard approach of using Keycloak actions and the Admin API instead.
If you've made it this far, congratulations, you win at Stack Overflow :-)
I need to log in a user into Dropbox using Core API. Then remember his/her access token and allow logging in with another credentials (looks like a second Dropbox user). But when I make request to https://www.dropbox.com/1/oauth2/authorize it automatically ends up with redirect page with first user's access token giving no chance to enter another credentials. I know I can revoke first access token but then I will not be able to silently come back to first user.
Does anyone know is the possible to implement?
You can set the force_reapprove parameter for the /authorize page to true to prevent the automatic redirect:
https://www.dropbox.com/developers/core/docs#oa2-authorize
Note that the /authorize page is hosted on www.dropbox.com though, so the user will get their www.dropbox.com session, even if force_reapprove=true is set. With that parameter set though, the user has the opportunity to switch accounts, using the dropdown in the upper right of the page, before authorizing the app.
If that's not sufficient for whatever reason, you can try to end the user's www.dropbox.com. The simplest way is to direct them to www.dropbox.com/logout first. Be sure to make it clear to the user what is happening though.
Or, if you control the entire browser, e.g., if it's an embedded web view in your app, you can clear the browser's cookies, which will clear the session, forcing users to log in again.
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.
What happens when you log into a website?
I know cookies are stored and some info (what info?) gets sent to the server...but maybe some more detail?
Once upon a time, somewhere on the Internet....
Browser: "hey, can I see this web page?, Trouble is, I don't remember speaking to you before"
Website: "sure, fill in the form, I need your username and your password"
Browser: "Here ya go"
Website: "Great!, Welcome back koldfyre! Here's the page. Look, if you want more pages, take this token and use it when you ask for another one"
Browser: Cool. That site gave me a token. I'll memorize it!
A few minutes later
Browser: "Ooh! Can I see this other web page? Here's my token"
Website: "That token looks good, hello again koldfyre, here's your web page"
That, in essence, is it. In order to remember a user has logged in, it gives the user a token which it must present with its next request. This is normally achieved by the server telling the browser to store this token in a cookie.
Delving deeper - transport layer authentication
The way the credentials are passed to the server, and the nature of the token it returns, vary depending on the authentication method employed.
The very simplest, HTTP Basic Authentication, is provided by most web server implementations. It causes your browser to pop open the familiar login dialog box. The "token" is simply your plaintext username and password base64 encoded. Not particularly secure.
A server might also provide Digest Authentication, which avoids transmission of the actual credentials - the client instead generates a hash of their credentials with a server generated salt. It is designed to prevent password sniffing and replay attacks.
Deeper still - application layer authentication
For maximum flexibility and control, most sites opt to implement the authorization in the application layer rather than the HTTP transport layer. This gives a wider variety of security choices. Any site which asks for credentials in a web page (rather than the browser's login dialog box) is using a custom authorization method.
Custom methods will vary wildly in their initial interaction, but they almost always result in the user being given a session cookie containing a randomly generated identifier. The browser then automatically presents the cookie with each subsequent request. The web application will inspect the cookie value to ensure it is still valid.
It's also possible to hand off the authorization to a trusted third party, generally to provide some sort of single-signon service. In cases like that, when you notice a user isn't authenticated, you bounce them off to the authentication provider. They authenticate them, and they will be returned to you with some kind of token you verify with the provider. Shibboleth is one example of this. You also logged into this very site using a similar method employed by OpenID
Further reading
Here's some nice answers from a similar question
PART I: How To Log In
PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox
PART III: Using Secret Questions
PART IV: Forgotten Password Functionality
PART V: Checking Password Strength
PART VI: Much More - Or: Preventing Rapid-Fire Login Attempts
PART VII: Distributed Brute Force Attacks
Other answers in that question provide even more links to round out your education!
That's a pretty general question. What you're doing, over all, is establishing some kind of credentials with the site itself. If we take the simple version, you enter a user name and a password; that means you identify yourself to the website, and then show it a secret you and the website share that no one else knows (we hope). That establishes you as authentically the person with that user name, and so we say you have authenticated yourself.
Once you've done so, there are some design decisions the website designer has to make. most people don't want to log in for every page, so the web site wants to store a little information, a credential, on your end. This means that it can tell it's still you. Often, as you say, that's a "cookie", which is nothing more that a tiny text file named with the web site's URL. This file is stored by the browser.
On many web sites, like for banking, you also want to guarantee that the data being exchanged can't be intercepted by a third party. If so, you establish a secure connection using a protocol known as SSL or TLS. What this adds to the basic connection is an exchange of information that establishes a session key. This session key is then used to encrypt the communications. This usually happens before you exchange the user name and password, so that your password is never visible to a malicious third party either.
Under the covers, when you establish a secure connection, the web site sends your browser a block of formatted data called an x509 certificate. This is another form of authentication; the certificate will have been signed by an issuer (the certificate authority or "CA") and the browser can use stored data about the CA's to ensure that the certificate is authentic.
This completely depends on the implementation of the website. Even the usage of cookies is not mandatory, but very common.
In most cases however, something like this happens:
You send in your username and password using an HTML form.
The server looks up the relevant user (using a database)
The server checks if the password matches the password that is stored in the database alongside the user.
If the password is correct, the server will store what user currently is active in the session. The identifier of this session is stored in a cookie, the actual data of this session (the current user) is stored on the server under this identifier.
Now you are logged in. You will remain logged in during the remainder of the session:
When you request another page from the server, you will send the cookie with the sesison identifier.
The server loads the session using this identifier. In this session, the current user is stored, so the server knows what user is logged in.
When you log into a web site, first your credential are authenticated. If your credentials match, then something is put into the session (on the server) to keep track of who you are so you can access data that is yours without having to re-log-in. This is obviously useless on the web server unless the client can provide information about who it is on each request. Note that the "Session" is usually maintained entirely on the web server, with the client having only a key that allows access to the session.
Remember that HTTP itself is a stateless protocol. The HTTP standard contains no method for HTTP requests to keep or persist any state between individual HTTP requests. Thus, the state is usually kept entirely on the server and you just need a method for the client to identify which session the current HTTP request belongs to.
The two common ways this is done are:
Use a cookie (for example, Apache Tomcat uses the JSESSIONID cookie) to store some hashed authentication token that will successfully look up the web session, or
rewrite the URL so that every request has the session ID added to the end of the request. Still using Apache Tomcat as the example, if cookies are disabled then the URL will be rewritten to end with a string like ";jsessionid=....". Thus, every request, every HTTP GET and POST (and the rest) will end with this string.
Thus, on each request the client makes, the session ID is provided to the web server, allowing the persisted state for this client to be quickly looked up, allowing HTTP to act like a stateful protocol.
What information is sent to the server when you log in? Whatever information you provided on the login form. Some web servers also track the TCP/IP address the request came from to avoid session hijacking attacks. This is usually all the information that is needed by the server.
If you don't allow your browser to save cookies, then you will have to log in to the web server each time you open your browser and initially open the server's web page. However, if you allow your browser to save cookies, then many servers allow you the option of saving the cookie (that is, not just using a session cookie) so that each time you go to a web page of the server, the persisted cookie will identify you so you don't need to re-login. Here, the cookie will save enough information -- often in an encrypted form that only the server can understand -- to identify you. In this case, the Cookie is not a simple session ID.
Very simply explained, what happens is mentioned below:
What goes in?
Username
Password
What happens inside?
Password is converted to its hash
Hash(password) is compared with the DB table or a Directory Service
(unless someone is down-rightly foolish, the site won't save your password in clear text)
If Authenticated, A status-token is stored in Session and/or cookie.
This token can just contain a status, Login Timestamps, your userId, userType(if any), et al.
This token is read and verified on every page you access if that page requires you to be logged with as a certain type of user.
If authentication fails, you are redirected to a page displaying error asking you to re-login.
What comes out
You are redirected your personal profile page/the page you were accesing to which verifies you with the help of the token.
Additionally, a Digital Certificate may come in picture if you are accessing a banking site or other critically secure site
There are two main ways of performing authentication on the web, and a few less popular ways that are also worth knowing about.
The first is HTTP authentication, as defined by RFC 2617. When you request a protected page, the server responds with a 401 status code, signalling that you aren't permitted to access the resource. In addition to this, it also sends a WWW-Authenticate header, which instructs the browser on how it wants you to authorise yourself. The browser sees this status code and the header, and prompts you for your authentication details. When you enter them, your browser prepares them according to the specific authentication scheme the server specified, and requests the page again, including an Authorization header with the prepared details. The server checks these details against its user database, and either responds with another 401 (wrong details), or the protected page with an accompanying 200 status code to indicate success.
HTTP authentication is one of those ancient features that browsers didn't implement well to begin with and have never really been improved. Because of this, it has become much more popular for web developers to implement authentication themselves using cookies to persist state. In this case, the user is presented with a standard HTML form. When the user enters their credentials into the fields and submits the form, the browser encodes it and sends it to the server in the same way it encodes any normal HTML form. The server checks the credentials, and if they are legitimate, sets a cookie with a randomly-generated ID number, along with a corresponding database/filesystem entry that recognises that ID number as belonging to a particular user.
From this point on, every request the browser makes to the server includes this ID number cookie as an HTTP header. The server recognises the cookie, looks up the ID number, and knows which user you are. When you choose to log out, the server sends a response asking your browser to forget the ID number, at which point you are just another anonymous user.
A less commonly-used option is the use of SSL client certificates. Many people are familiar with the idea of using SSL to identify a server. A cryptographic keypair is generated, signed by a trusted authority, and used to prove that the data being sent originated with the owner of the keypair. What many people aren't aware of though, is that the same can be used by a client to prove its identity to a server. This is less convenient, however, as you need to carry your certificate around with you if you want to use it on more than one machine.
There are variations and lesser-known options available of course, but these are the most prominent ones.
As others have mentioned, login procedures vary depending on implementation, but the basic case (simple web app authentication) uses something like the following pseudocode:
function login(username, password) {
user = db->get_user(username)
if (user == false) {
report_error("Unknown username")
exit
}
if (user->password != hash(password)) {
report_error("Incorrect password")
exit
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
}
Of course, in most cases, it gets a little more involved than that, but every login function starts its life looking essentially like the above. Now, if we add autologin ("remember me") to the mix, we get something like this:
function login(username, password, remember_me) {
user = db->get_user(username)
if (user == false) {
report_error("Unknown username")
exit
}
if (user->password != hash(password)) {
report_error("Incorrect password")
exit
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
if (remember_me == true) {
cookie_token = random_string(50)
set_cookie('autologin_cookie', cookie_token, ONE_MONTH)
// Finally, save a hash of the random token in the user table
db->update_user(user, 'autologin_token', hash(cookie_token))
}
}
Plus the function to perform the automatic login if there is a cookie present:
function cookie_login() {
cookie = get_cookie('autologin_cookie')
if (cookie == false) {
return false
}
// Only for demonstration; cookie should always include username as well
user = db->get_user_by_cookie(cookie)
if (user == false) {
// Corrupt cookie data or deleted user
return false
}
// User authenticated, set session cookie
session->set_data('current_user', user->username)
return true
}
NOTE: The above isn't a 'best practices' approach, and it's not very secure. In production code, you would always include a user identifier in the cookie data, use several levels of throttling, store data on failed and successful logins, etc. All of this has been stripped away to make the basic structure of authentication simple to follow.
Anyway, I hope this is what you were looking for, koldfyre. I don't know your background, but if you're unsure of how sessions and cookies work, you should read up on them separately, and if you need more elaborate details, just ask.
P.S.: You may also want to check the question "The Definitive Guide To Website Authentication" for best practice approaches
Look, it's a little hard to give you a lot more information that you already have here; I'm not sure why you want to set a bounty on it. A cookie is just a little bit of named information, and you can put anything you like in it. For a session, you'd want some kind of session ID. There are conventions for that, or you can do it yourself. Whatever you do, when you set the cookie, you leave a little data lying about on the person's browser that is more or less like this:
mydomain.com:
mystuff: this is my stuff, by golly.
When you come back, you retrieve the cookie and get that back.
If you want to see all the details of that protocol, have a look at the Wikipedia article.