---
title: 'Getting Started with Keycloak in 2026 (Free Identity Server Alternative)'
source: 'https://youtube.com/watch?v=neqUYC61tUM'
video_id: 'neqUYC61tUM'
date: 2026-08-08
duration_sec: 783
---

# Getting Started with Keycloak in 2026 (Free Identity Server Alternative)

> Source: [Getting Started with Keycloak in 2026 (Free Identity Server Alternative)](https://youtube.com/watch?v=neqUYC61tUM)

## Summary

This video provides a practical, step-by-step guide to getting started with Keycloak, an open-source identity and access management platform. It demonstrates how to run Keycloak locally using Docker, create a realm and client, and obtain an access token using the industry-standard authorization code flow with PKCE. The tutorial also explains how to validate the token and retrieve user information, making it a comprehensive introduction for developers.

### Key Points

- **Introduction to Keycloak** [00:02] — Keycloak is an open-source, free identity and access management platform (identity provider) that simplifies adding authentication to applications and securing APIs.
- **Running Keycloak with Docker** [00:15] — Keycloak can be run locally using a Docker container. The video shows a docker run command and then a Docker Compose file using the keycloak:26.5.0 image with the start-dev command for development mode, exposing port 8080.
- **Configuring Docker Compose** [01:24] — The Docker Compose service defines environment variables for the admin username and password, runs in development mode with an embedded database, and maps port 8080.
- **Accessing the Admin Console** [02:18] — After starting the container, access the Keycloak admin console via the browser, sign in with the admin credentials, and create a new realm (e.g., 'demo'). A realm is a logical grouping of clients and users, similar to a database schema.
- **Understanding Clients and Standards** [02:45] — Clients represent applications that request authentication. Keycloak implements OAuth 2.0 and OpenID Connect (OIDC), an identity layer on top of OAuth, to authenticate users and obtain access tokens.
- **Creating a Public Client** [03:26] — Create a new client with type OpenID Connect. Choose 'public' for client-facing applications (e.g., SPA, desktop) where a client secret cannot be securely stored. For the authentication flow, select 'authorization code' and set PKCE method to SHA-256.
- **Setting Redirect URIs** [04:31] — Set the valid redirect URIs to the Postman callback endpoint to allow the authorization code flow from Postman. Save the client configuration.
- **Creating a Test User** [04:58] — Create a dummy user (e.g., test@test.com) with credentials (password: 123123) and mark email as verified. Disable temporary password to use these credentials for testing.
- **Authorization Code Flow with PKCE** [05:22] — The flow: user clicks login, app generates a code verifier (random string) and hashes it to create a code challenge. It sends an authorization request to Keycloak's authorize endpoint, redirects user to login, and upon success, Keycloak returns an authorization code. The app then sends the code and code verifier to the token endpoint; Keycloak validates the code and hashed verifier, and returns an ID token, access token, and refresh token.
- **Security Purpose** [07:26] — The complexity of the flow is intentional to harden security and prevent attacks where an authorization code is compromised, as the attacker cannot exchange it without the code verifier.
- **Using Postman for Token Request** [07:54] — In Postman, use the Authorization tab, select OAuth 2.0, grant type 'Authorization Code (With PKCE)', set callback URL, authorization URL, and token URL. Obtain these from the well-known OpenID configuration endpoint: /realms/demo/.well-known/openid-configuration.
- **Obtaining Access Token** [09:15] — Set client ID 'public', code challenge method SHA-256, and click 'Get New Access Token'. This redirects to Keycloak login; after authentication, Postman receives an access token and refresh token.
- **Inspecting JWT** [10:11] — Paste the access token into jwt.io to view the header, payload, and signature. The payload includes issuer (demo realm), subject (user ID), and other claims for authorization.
- **Validating Token Signature** [10:36] — APIs validate the token signature by fetching the public key from Keycloak's JWKS endpoint (e.g., /realms/demo/protocol/openid-connect/certs) and using it to verify the signature in jwt.io.
- **Fetching User Info** [11:32] — Call the userinfo endpoint (/realms/demo/protocol/openid-connect/userinfo) with the access token. Initially returns 401/403 because the 'openid' scope was not requested; adding 'openid' to the scope and re-requesting the token yields a 200 response with user details.
- **Token Refresh** [12:27] — Postman can automatically refresh the access token if the option is enabled, allowing seamless authenticated requests.

## Transcript

If you want to add authentication to your application or secure your APIs and do all of that with minimum effort, then Keycloak is the solution for your problems. In this video, I'll show you how you can get started with Keycloak,
how you can run it locally in a Docker container, and how you can use it to obtain an access token using the industry standard authorization code flow. Keycloak is an identity and access management platform, what you would
typically call an identity provider. It's open source and free to use, and it's easy to run it as a Docker container. There's a useful guide on their website how you can get started with running Keycloak. And I'm going to
copy this command here that's going to start a container running Keycloak using the latest version. Now, to make this repeatable, I'm going to add a Docker Compose file in my folder. And let me copy this command. Now to be able to
better see what we have going on here, let me add a couple of more lines and I'm going to extract the individual arguments here. So we have a docker run exposing keycloak on a local port. This is the image that we're going to run. So
we're running keycloak version 26.5.0 and we have an additional command here called startdev to run keycloak in development mode. So then I'm going to first service. And you can see I'm getting a code completion here. So we're
going to define the keyflow service. We want to run the image that we have above version 26.5.0. We are also setting some environment variables which represents the admin username and password. You're going to
use this to access the key management console. We are running it in development mode which is going to use an embedded database and we're making it available on the local port of 8080. So then to run this I'm going to need a new
terminal and I'm going to say docker compose app. This is going to build my docker compose file fetch any images that might be missing and it's going to start keylo. If I open up docker desktop you can see that we have the keylo
container running locally and if you're running it for the first time it might take a couple of moments for keylo to become responsive and start accepting your requests. When you access Geeklo at this address and you should see a user
interface that looks something like this. Here we can input our admin username and password and sign in. And this should unlock access to the keycloak management console. From here I'm going to click manage realms and I
demo. And for lack of a better name I'm going to call this realm the demo realm. So we are now in this realm and you can think of a realm as a logical grouping of clients representing applications and any users that might be a part of it. A
nice way I like to think of it is it's like a schema inside of a database. Now the clients represent applications or services that can request authentication on behalf of a user. So, Keycloak implements the popular OOTH2 standard
which we use to be able to reliably authenticate a user to obtain an access token and then we use that access token to access any protected information on a resource server. Keycloak also implements open ID connect which is an
identity layer on top of OAF. Now you can see our realm comes with a bunch of needing. Instead we want to create a new one. And for the client type I'm going to choose open id connect. Then we have to give our client a unique ID. I'm just
going to call this the public client because I want to use it from some sort of client-f facing application where I can't securely store a client secret. An example of this might be a single page application or a desktop application.
And a secure application might be a web app running on some server in the cloud where you can securely store a client secret. From here, I'm going to click next. And from this screen, we get to choose if this is going to be a public
client or a confidential client. If we leave it off, it's going to be a public client. And from the authentication flows, we are most interested in the authorization code. You could also use a direct access grant where you can
directly exchange a username and password for the access token. Although typically want to do this with a confidential client. So I'm going to leave just the default settings here. And for the PKCE method or Pixie, which
is short for approve key for code exchange, we want to choose which hashing algorithm we want to use when hashing the code verifier. I'm going to explain what this is in just a moment. But I'm going to choose SHA 256. And I'm
going to click next. And here we just want to set the valid redirect URIs. And I'm going to add this value which is a callback endpoint for Postman is going to allow us to use the authorization code flow from our local Postman
instance. So with this I'm going to click save and we have our public client. Now the second thing we need is a user to be able to authenticate with. just going to create a dummy user. Let's say test.com.
Let's use the same for the email and then the first name are going to be test and test. Now I'm going to say that the email is verified and create this user and we want to give them a set of credentials. I'll just say 1 2 3 1 2 3
and turn off temporary because I actually want to use these credentials. So now we also have a dummy user. The next thing we need is to understand the authorization code flow. Here's a diagram explaining how the authorization
code flow with Pixie works in practice. I got this image from off zero which is why you see off zero here. But in our example this here is going to be keyloak. So how does the authorization code flow with Pixie work in practice?
We have a user inside our application that wants to log in and they click some login link in the application which does two things. It generates a code verifier which is some cryptographically safe random string and it hashes it to
produce a code challenge. This is the pixie part of the authorization code flow. It then sends an authorization code request with the code challenge that we generated in the previous step to our authorization server which is
keycloak and there's a set of standard endpoints that you can call for this and the one for obtaining an authorization code is the authorize endpoint. What code is the authorize endpoint. What happens next is we redirect the user to
the login screen of our authorization server in this case keycloak where the user enters their credentials and then keycloak is going to validate these credentials and if it confirms that they are successful it's going to redirect
the user back to our application but it's also going to return an authorization code. We then send this authorization code together with the code verifier that we generated at the start of this entire flow back to our
authorization server keycloak. What happens is keycloak stored the code challenge from our previous step. And when we try to exchange an authorization code for an access token is going to validate if the authorization code is
valid. And it's also going to check the code challenge that is stored previously and compare it to the code verifier which gets hashed. And if these values are the same, then it's going to return an ID token and an access token together
also with a refresh token and return those to our application. Finally, our application is able to request user data from our resource server, which is typically your API using the access token that we obtain. So you can see all
of this is pretty complicated and rightly so because the purpose of this is to harden the security of your application, prevent many type of attack authorization code is compromised because an attacker won't be able to
exchange it for an access token without the code verifier that we generated at how the authorization code flow with Pixie works and how do we actually use this in practice. I'll switch to my Postman instance and if you try to send
authorization tab here where you can choose OAF 2.0 for the authentication type. Now we are obtaining the bearer token. So I'm going to leave the header prefix as the default value and what we
want to choose is the grant type. This basically represents which flow you want to use to obtain an access token. In our case, authorization code with proof key for code exchange. Then you can set the call back URL or you can use the default
one from postman which we configured earlier in our keyflow client if you remember. You can also set this value manually. Then we have to provide the authorization URL which is used to get the authorization code and the access
token URL. So how do we get these values? Most of these things are standardized and we can send a request to our key instance which if you recall is running on port 8080. Now we have to scope our request to the current realm
which is called demo. And the endpoint I want to call is wellnown /open id configuration. If we send this request we should get back a successful response which contains some publicly available information for your keylo realm. Now
out of all of these what we are interested in is the authorization endpoint that we can set here and this is where we get our authorization code and also the token endpoint that we can use to obtain an access token. So let's
set both of these values. Then our client ID is just public. This is what configure the code challenge method as Here's the field for adding a code
generate this. and you want to scroll all the way down and click get new access token. So this is going to redirect you to where keycloak instance where you can authenticate on behalf of a user. So if I add the user's
credentials and click sign in, keycloak is going to verify this information and to Postman which is then going to request an access token which you can see here. So we get an access token and a refresh token back in the response.
You can also see the grant type here as authorization code with proof key for code exchange. So if we grab this access token and we head over to jwt.io, we can drop in the value that I just copied from Postman and take a look at
what we have inside of the access token. So you can see which algorithm was used to sign this value, the contents of the header, the payload, and the signature. And inside of the payload, we can see who is the issuer, our demo realm, which
we created at the start of the video. We can see a unique ID for the currently authenticated user in the subject claim and then a bunch of additional claims for this user that we can use for authorization purposes. For example, if
you're wondering how our application is able to verify that this is a valid access token, it does so by validating the signature, which you can actually do here by adding the public key. If I go back to Postman for a moment and our
open ID configuration, there's a value here that contains the public keys for our key cloak realm. If I call this endpoint, I can get the public keys back. Here's the public key for the RSA algorithm, but we are actually using the
RSA 256. So this is the public key value. And if I add this in JWTIO, but I have to prefix it with begin certificate and end certificate and then paste it in this format. You can see that we are able to validate the signature of our
access token. So this is essentially what our API does to validate the access token. It reaches out to key cloak, gets back the public key and then uses it to verify the signature that is part of the access token. Finally, because we lack a
backend API to test this against, I'm going to call this endpoint on our realm. It's protocol/open id connect/ user info. And this should allow me to currently authenticated user. Now you can see that I'm getting back a 401
unauthorized response. This is probably because I didn't choose which token to use. So let's choose the one we got earlier. And now the response changes to 403 forbidden, which means we know who you are, but you don't have access to
this resource. And the reason for this is because this is an open ID connect endpoint and I didn't request the open ID scope when I retrieved the access token. So if we add open ID in the scope field and we send another request to get
the access token and we use this token and I resend the same request, you can see that we now get back the 200 okay response which contains the information for the currently authenticated user. And this is how we could obtain the
current user's info from our keyloak instance. If you don't want to go new access token inside, you should leave this option on where Postman is going to automatically refresh your access token and you can seamlessly
continue sending authenticated requests to your API. So this covers how to get started with Keyflo locally and use the authorization code flow. If you want to see how you can integrate Keycloak with your backend API running innet, then go
ahead and check out this video next. Make sure to smash the like button if you enjoy this video. Thanks a lot for watching and until next time, stay watching and until next time, stay awesome.