Build an OIDC Identity Lab with Keycloak

Run a local Keycloak lab to test OIDC login, redirects, SSO, and tokens.

Introduction

30 Second Summary

When an application asks for your password, you have to trust that it checks the secret safely. Repeating that trust across many applications creates more places where the password could be exposed.

In this project, you will build a local sign-in lab with Keycloak. You will see how an application sends you to a trusted login page, then welcomes you back after Keycloak confirms who you are.

What You'll Build

A single click on Sign in sends your browser to Keycloak before returning you to the test application with a greeting that shows who signed in.

By the end of this project, you'll have:

A working local sign-in lab where Keycloak checks the password for a test application. The application learns who signed in without handling the password.
A visible return-address safety check that blocks the browser from returning to an address you did not approve.
A simple map of sign-ins and tokens that explains how one login can work across applications. You will also learn the separate jobs of ID, access, and refresh tokens.
Secret Mission: Open Keycloak's service directory and match five addresses to jobs such as signing in, getting tokens, and signing out.

Are there any prerequisites?

You need a Linux device, internet access, and Firefox or a compatible browser. Your Linux account must be allowed to make system changes during installation.

You do not need previous identity and access experience. The project checks for Docker Engine and helps you install it when needed.

Before We Start

Before any hands-on work, define the fictional web application this local sign-in lab protects. This gives you a clear reason for letting Keycloak check the username and password for the application.

Set Up Docker and Start Keycloak

Most applications need a trusted system to check usernames and passwords. An identity provider does that job for them, and this local lab lets you see every part of the sign-in process.

You will use Docker to run Keycloak inside a container. A container is a ready-made package that includes the software and the environment it needs, so you do not have to install Java separately.

In this step, get ready to:

Check whether Docker is already installed.
Give your Linux account permission to run Docker containers when needed.
Start Keycloak 26.8.1 and open its Admin Console in Firefox.

Install Docker Engine safely

Docker Engine is the part of Docker that starts and stops containers. You need it before your device can run the ready-made Keycloak package.

The installer needs permission to change system files. Its dry run shows the planned changes without installing anything, so you can review them first.

Before you run the first check, predict whether Docker is already ready to start a container.

Check whether Docker can already run a container by running this command:

docker run hello-world

What does this check do?

When Docker is available, the command downloads a small test image.
Docker starts the test container.
The container prints a confirmation message before it exits.

✔️ Docker prints its confirmation

Docker Engine is already installed. That first container confirms the engine can download an image and run it.

ⓧ I see command not found

Docker is not installed yet. You will download Docker's official development installer and preview its changes before allowing it to modify system files.

Download the official Docker development installer into your current terminal directory by running this command:

curl -fsSL https://get.docker.com -o get-docker.sh

What does this command download?

The command saves the official installer as get-docker.sh. The next command previews what that script proposes to change.

Preview the installer's system changes by running this command with administrator permission:

sudo sh ./get-docker.sh --dry-run

Why run a dry run?

The dry run detects your Linux distribution. It displays the planned installation actions without installing Docker Engine.

Read the dry-run output.
Stop this project if the script does not recognize your Linux distribution.
Install Docker Engine after the script recognizes your distribution by running this command:

sudo sh get-docker.sh

What does the installer add?

The script installs Docker Engine and the supporting tools it needs. The installation may take a few minutes while your device downloads the packages.

Docker installation failed?

Confirm that the dry run recognized your distribution. Check that your account can use sudo.

Check your internet connection if package downloads stop.

Help me diagnose the Docker development installer failure.

ⓧ Docker cannot run the container

The Docker command exists, but your account could not run the test container. The next substep gives your Linux account permission before you try again.

Let your account run Docker

Linux limits who can send commands to Docker. Adding your account to the docker group grants permission to run Docker without the administrator command sudo each time.

This access is powerful because Docker can control software running on your device. Apply the group change only if the first test container failed because your account lacked permission.

Skip the group commands if your first hello-world run printed Docker's confirmation message.
Grant the current user Docker access after an access failure by running these commands:

sudo groupadd --force docker
sudo usermod -aG docker $USER
newgrp docker

What do these commands change?

The first command makes sure the docker permission group exists.
The second command adds your Linux account to that group.
The third command opens a new terminal session that uses the updated permission.

Before you run the final Docker check, predict what a working engine prints after the test container starts.

Verify Docker access by running this command:

docker run hello-world

What should you see?

Docker prints its confirmation message before the test container exits. This proves that the current user can download images and run containers.

Docker still cannot run the container?

Confirm that newgrp docker opened a new terminal session before you repeated the check. Docker also fails to start containers when its background service is stopped.

Help me diagnose why my Linux user cannot run Docker containers.

That is the foundation in place. Your Linux account can now run the containers used in this identity lab.

Launch Keycloak in local development mode

Keycloak provides the login page and checks the username and password. After a successful sign-in, it tells the registered application which user has been verified.

The Keycloak command keeps using the terminal while the server runs. The first launch may take a few minutes because Docker must download the Keycloak package.

Keep this development server local

The start-dev mode uses simple settings meant for a short local lab. The address 127.0.0.1 keeps Keycloak available only on your Linux device.

A public Keycloak server needs encrypted HTTPS connections, a production database, and a strong administrator password.

Start Keycloak in local development mode by running this command:

docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.8.1 start-dev

What does this command start?

Docker downloads the Keycloak 26.8.1 package if your device does not already have it.
The 127.0.0.1:8080:8080 setting makes Keycloak available at local port 8080 only on your device.
The two administrator settings create the first administrator with username admin and password admin.
The start-dev setting starts Keycloak with local development defaults.

Leave the Keycloak terminal open.
Open your Linux desktop's application search.
Search for Firefox.
Select Firefox from the search results.

Before you open the Admin Console, predict what the browser should display while the Keycloak container is running.

Enter http://localhost:8080/admin/ in the Firefox address bar.

You should see the Keycloak Admin Console login page. Your local identity provider is live and ready for its first group of users and applications.

Admin Console page not loading?

Confirm that the terminal running Keycloak remains open. Wait for startup to finish if Docker is still downloading the Keycloak package.

Check the terminal for a message saying port 8080 is already in use. Another application can prevent Keycloak from using the same port.

Help me diagnose why the local Keycloak Admin Console is not loading.

✔️ Awesome, everything is running

Docker Engine works for your current user. Keycloak is running locally with its Admin Console ready for sign-in.

ⓧ I'd like to double check the final state

Confirm Docker Engine is installed on the Linux device.
Confirm your Linux account can run Docker commands.
Confirm docker run hello-world prints Docker's confirmation message.
Confirm the Keycloak container is still running in the terminal.
Confirm Keycloak is limited to your device through 127.0.0.1:8080:8080.
Confirm Firefox displays the Admin Console login page at http://localhost:8080/admin/.

Your local identity provider is running. Next, you will create a separate space for this lab's users and applications.

Create a Realm and Test User

Your local Keycloak server is running. It now needs a separate place to hold the test user and the applications that will use that person's sign-in.

Keycloak calls this separate place a realm. Think of a realm as its own locked workspace with its own users, applications, and sign-in settings.

In this step, get ready to:

Create the separate myrealm realm.
Create myuser with a lab-only password.
Sign in as myuser through the Account Console.

Create the separate realm

The admin account manages the whole Keycloak server. You will use it to create myrealm, which keeps the lab user separate from the account that controls Keycloak itself.

Return to the Firefox tab showing http://localhost:8080/admin/.
Enter admin in the Username field.
Enter admin in the password field.
Submit the login form below the password field.
Select Manage realms in the left column.
Select Create realm.
Enter myrealm in the Realm name field.
Select Create.

You will see myrealm beside Current realm. This confirms that the lab now has its own space for users and applications.

Why keep applications out of master?

The master realm manages Keycloak itself. Keeping application users in myrealm separates lab identities from server administration.

Can't create myrealm?

Confirm that the Keycloak terminal from earlier is still running. A stopped development container makes the Admin Console unavailable.

Check whether myrealm already appears beside Current realm before trying to create it again.

Ask for help: Help me diagnose why I cannot create myrealm in my local Keycloak Admin Console.

Create the test user

A user is the identity record inside the realm. The password proves control of that identity during sign-in.

Confirm that myrealm appears beside Current realm.
Select Users in the left-hand menu.
Select Create new user.
Enter myuser in the Username field.
Enter Jamie in the First name field.
Enter Rivera in the Last name field.
Select Create.

You will see the details page for myuser. The identity record now exists inside myrealm.

Keep the password in the lab

Password setup is the sensitive part of this step. A unique lab-only value keeps your real account credentials outside Keycloak.

Select Credentials at the top of the user page.
Select Set password.
Enter a unique lab-only password in the first password field.
Re-enter the same password in the confirmation field.
Set Temporary to Off.
Submit the Set password form.

Keycloak confirms the password update in the Admin Console. The user is ready for a real sign-in test.

Prove the user can sign in

Authentication answers, “Who are you?” by checking sign-in details such as a password. Authorization answers, “What are you allowed to do?” after the user is known.

Before you test, do you think myuser can sign in before you register a separate test application?

Create a new tab in Firefox.
Enter http://localhost:8080/realms/myrealm/account in the address bar.
Enter myuser in the username field.
Enter the lab-only password you just created in the password field.
Submit the login form.

You will see the Account Console for myuser. This proves the user can sign in to myrealm before you register the separate test application.

What did this sign-in prove?

Keycloak accepted myuser and the lab password. This confirms that the user record works inside myrealm.

You have checked who the user is. The next step decides which application may use that sign-in.

✔️ My realm user can sign in

Your separate realm now contains a working test user. The Account Console proves that myuser can sign in successfully.

ⓧ I'd like to double check the final state

Confirm that Docker Engine remains usable by your current Linux user.
Confirm that quay.io/keycloak/keycloak:26.8.1 remains downloaded locally.
Confirm that Keycloak remains running at http://localhost:8080.
Confirm that myrealm exists as an isolated realm.
Confirm that myuser has the profile name Jamie Rivera.
Confirm that myuser has a unique lab-only password credential.
Confirm that Temporary is set to Off.
Confirm that Firefox shows the signed-in Account Console for myuser.

Your separate sign-in workspace now works. Next, you will register an application and let it use myrealm for login.

Register an OIDC Client and Sign In

Your myrealm workspace can already recognize myuser. Now you will give one test application permission to ask Keycloak to handle its sign-in.

In OpenID Connect, an application registered with the sign-in provider is called a client. The registration tells Keycloak which application is asking and which browser address it may send the user back to.

In this step, get ready to:

Register the public client myclient.
Complete a visible sign-in through the official test application.
Trace the login from the application redirect to the token exchange.

Register myclient

A client is Keycloak's saved record for an application. This record connects the application to the realm and lists the sign-in options it may use.

Switch back to the signed-in Keycloak Admin Console tab from earlier.
Confirm myrealm is selected in the realm selector.
Select Clients from the left sidebar.
Click Create client.

You will see the client creation page. The settings you save here tell Keycloak how the test application may use sign-in.

Choose OpenID Connect for Client type.
Enter myclient in Client ID.
Click Next.

You will see settings for the sign-in method. These controls decide whether the browser application needs its own secret and which login journey it can start.

Leave Client authentication set to Off.
Confirm Standard flow is enabled.
Click Next.

You will see Login settings. This page lists the browser addresses that Keycloak may trust for this application.

The trailing wildcard is easy to miss. It covers the test application's return path beneath /app/.

Enter https://www.keycloak.org/app/* in Valid redirect URIs.
Enter https://www.keycloak.org in Web origins.

The two fields now contain the test application's approved return address and website address.

Click Save.

The application registration is ready. Keycloak now recognizes myclient and knows which return path it may use.

Why is this a public client?

A browser application is a public client because any secret stored in its page could be inspected by the person using the browser. That is why Client authentication stays Off.

Standard flow lets the browser visit Keycloak's login page and return with a short-lived code. The application trades that code for the sign-in result, while the password stays with Keycloak.

Client settings not saved?

Confirm myclient appears under Clients in myrealm.
Confirm Client authentication is set to Off.
Confirm Standard flow is enabled.
Confirm Valid redirect URIs contains https://www.keycloak.org/app/*.
Confirm Web origins contains https://www.keycloak.org.

Help me check my Keycloak OIDC client configuration.

Complete the visible login

The test application does not ask for the password itself. Firefox carries you to Keycloak's login page, then brings you back after Keycloak confirms the sign-in.

Why use the test application?

The official test application gives you a working sign-in screen without asking you to write application code. This keeps your attention on what moves between the application and Keycloak.

A later project replaces this borrowed application with software you control.

Create a new tab in Firefox from earlier.
Enter https://www.keycloak.org/app/ in the address bar.

You will see the test application's settings. These values tell it where Keycloak is running and which realm and client registration to use.

Confirm the Keycloak server is http://localhost:8080.
Confirm the realm is myrealm.
Confirm the client is myclient.
Click Save.

The test application now knows to send sign-in requests to your local Keycloak server.

Before you select Sign in, where do you expect Firefox to go before the application can show an authenticated greeting?

Click Sign in.

Firefox moves to Keycloak for sign-in. If Keycloak still remembers your earlier login in this browser, it can return you to the test application without asking for the password again.

A login form means Keycloak needs a fresh proof of identity. Your lab-only password stays on Keycloak's page.

Enter myuser in the username field if the Keycloak login form appears.
Enter your unique lab-only password if the password field appears.
Submit the Keycloak sign-in form if it appears.

You'll return to the test application. The page shows Hello, followed by the user's name.

That handoff works. The greeting proves that myclient can ask Keycloak to handle sign-in and receive the successful result.

No authenticated greeting?

Confirm the test application uses http://localhost:8080 as its Keycloak server.
Confirm the test application uses myrealm as its realm.
Confirm the test application uses myclient as its client.
Confirm the client's redirect value is https://www.keycloak.org/app/*.
Confirm myuser still has a non-temporary lab password.

Help me diagnose why the test application does not show an authenticated greeting.

Trace the Authorization Code flow

The greeting proves that the complete sign-in journey worked. Four small handoffs happened while the browser moved between the application and Keycloak.

This journey is called the Authorization Code flow. Keycloak first sends back a temporary one-use code, and the client exchanges it for tokens that describe the successful sign-in.

Follow the first handoff: the application sends your browser to Keycloak.
Follow the second handoff: Keycloak checks the username and password.
Follow the third handoff: Keycloak sends the browser back to the approved application address with a temporary code.
Follow the fourth handoff: the application exchanges that code for tokens that confirm the result.

Keycloak receives the password because it hosts the login page. The test application receives the authenticated result through the protocol flow.

How professionals handle this flow

Use a sign-in library that supports PKCE. PKCE gives browser applications an extra one-use proof when they exchange the temporary code for tokens.
Approve only the return addresses the real application uses.
Use the visible greeting as proof of success. Keep raw token strings out of screenshots.

Before the final check, do you expect the authenticated greeting to remain after the code exchange finishes?

Return to the test application tab in Firefox.

You'll still see Hello, followed by the user's name. This confirms that the registered client completed the flow successfully.

✔️ Awesome, I've got everything!

Your public OIDC client now completes a visible login through Keycloak. You can trace the successful flow from the initial redirect through the code exchange.

ⓧ I'd like to double check the final state

Confirm myclient appears under Clients in myrealm.
Confirm Client authentication is set to Off.
Confirm Standard flow is enabled.
Confirm Valid redirect URIs contains https://www.keycloak.org/app/*.
Confirm Web origins contains https://www.keycloak.org.
Confirm the test application shows Hello, followed by the name of myuser.

Your application can now use Keycloak for sign-in. Next, you will see how Keycloak protects the return address that receives the result.

Trigger a Redirect URI Failure

Your test application can now send you to Keycloak for sign-in and welcome you back afterward. That working greeting proves the application and Keycloak can complete the journey together.

Keycloak also checks where the browser is allowed to return. You will deliberately remove the application's exact return path so you can see this safety check block the sign-in.

In this step, get ready to:

Narrow the allowed return address for myclient.
Test sign-in with the changed client configuration.
Diagnose the return-path mismatch.

Replace the approved return address

A redirect URI is an address that Keycloak is allowed to send the browser back to after sign-in. The address must match the application's real return location, including its /app/ path.

Return to the Keycloak Admin Console from earlier.
Select Clients from the left navigation.
Select myclient from the client list.
Locate the Valid redirect URIs field.
Replace https://www.keycloak.org/app/* with https://www.keycloak.org.
Select Save.

The saved redirect field now contains https://www.keycloak.org. The Web origins field still contains https://www.keycloak.org.

Test the changed redirect

The application will still ask Keycloak to return the browser to its /app/ page. Your changed setting no longer approves that full address, so this test makes the safety check visible.

Switch back to the Firefox tab containing https://www.keycloak.org/app/.

Before you select Sign in, do you expect Keycloak to accept the application's /app/ return path when only the main website address is approved?

Select Sign in.

Keycloak refuses to send the browser back to the unapproved address. The test application does not show the signed-in greeting.

What did this failure prove?

The application asked Keycloak to return the browser to https://www.keycloak.org/app/.
The approved list contained only https://www.keycloak.org, so the /app/ path did not match.
Keycloak blocked the return before the existing login session could complete the application's request.

That rejection is the result you wanted. Keycloak is enforcing the saved list of approved return addresses.

Did the application still sign in?

Confirm that Valid redirect URIs contains only https://www.keycloak.org.
Select Save again if the updated value was not stored.
Confirm that the test application still uses myrealm with myclient.

Help me diagnose why the redirect test still succeeds.

Diagnose the path mismatch

The password check and the return-address check protect different things. A correct password proves who the user is, while the approved address controls where Keycloak may send the sign-in result.

Compare the application's return address at https://www.keycloak.org/app/ with the saved address https://www.keycloak.org.
Identify /app/ as the missing part of the saved return address.

Before changing anything, decide whether a new password for myuser could make these two addresses match.

Changing the password would not help. The failed control belongs to myclient's redirect configuration.

Why keep redirects narrow?

Every approved return address is a place that can receive a sign-in result. A short, exact list gives an attacker fewer addresses to misuse.

For a real website, approve only the HTTPS addresses the application uses. Compare the requested address with the saved address before adding a broader pattern.

Before the final check, predict whether an authenticated greeting can appear while myclient allows only the site root.

Switch back to the browser tab containing the rejected authorization request.

The signed-in greeting is still missing. This confirms that a correct password cannot overcome an unapproved return address.

✔️ Keycloak rejected the request

You reproduced the return-address safety check. Keycloak still remembers myuser's login, but myclient cannot use the unapproved /app/ return path.

ⓧ I'd like to double check the final state

Confirm that Client authentication remains set to Off.
Confirm that Standard flow remains enabled.
Confirm that Valid redirect URIs contains https://www.keycloak.org.
Confirm that Web origins contains https://www.keycloak.org.
Confirm that signing in from https://www.keycloak.org/app/ produces a rejected authorization request.

You traced the failure to the saved return address. Next, you will restore the missing path and prove that one active Keycloak login can work across two applications.

Repair the Flow and Map Tokens

The rejected sign-in showed that Keycloak checks the application's return address before sending the browser back. The username and password were not the problem.

You will fix only the saved return address. Keeping the other settings unchanged makes it clear which value caused the failure.

After the repair, you will open a second Keycloak page without entering the password again. This demonstrates Single Sign-On, which lets several applications reuse one active Keycloak login.

In this step, get ready to:

Restore the approved return path for myclient.
Prove that one active Keycloak login works in two applications.
Match the ID token, access token, and refresh token to their jobs.

Restore the approved return path

The redirect URI is the saved address where Keycloak may send the browser after sign-in. Restoring the application's /app/ path fixes the exact mismatch you created.

Switch back to the Keycloak Admin Console from earlier.
Select myrealm from the realm menu.
Select Clients in the left navigation.
Select myclient from the client list.
Find Valid redirect URIs.
Replace https://www.keycloak.org with https://www.keycloak.org/app/*.
Select Save.

The saved list now approves the test application's /app/ return path.

Before you retry the login, do you expect Keycloak to accept the same application request now? The next click tests your prediction.

Return to https://www.keycloak.org/app/ in Firefox.
Select Sign in.

You'll return to the test application. It displays Hello, followed by your user's name.

Why does this exact repair work?

The test application asks Keycloak to return the browser to an address beneath https://www.keycloak.org/app/.

The final * in https://www.keycloak.org/app/* approves pages below that path. It stays narrow enough to exclude unrelated parts of the website.

Reuse one login across two applications

After the first sign-in, Keycloak keeps a temporary browser login called a session. Single Sign-On lets another registered application ask Keycloak to reuse that session instead of showing the password page again.

Open a new tab in Firefox.

Before you visit the Account Console, do you expect another password prompt? Keep your prediction in mind during the check.

Enter http://localhost:8080/realms/myrealm/account in the address bar.
Press Enter.

You will see the Account Console recognize myuser without another password prompt. Keycloak reused the login from the first application.

What does this prove?

The test application and Account Console are two separate clients. Both asked Keycloak whether you already had an active login.

Keycloak recognized the same browser session for both clients. That shared sign-in experience is Single Sign-On.

Classify the token set

The Authorization Code flow finishes by trading a temporary one-use code for three tokens. Each token carries a different kind of proof, so applications use them for different jobs.

How do the three tokens differ?

ID token: tells the client who signed in, such as the user's name and identifier.
Access token: is the pass an application sends to a protected service when it requests data or performs an action.
Refresh token: lets the application request a new access token after the old one expires, without asking for the password again.

Handle tokens safely

Keep raw tokens out of screenshots.
Do not save raw tokens in code that other people can access.
Keep browser tokens only for as long as the application needs them.
Send an access token when the application asks a protected service for data or an action.
Ask Keycloak only for the permissions the application needs.

Before the final check, do you expect the Account Console to ask for the password while Keycloak still remembers your login? The two browser tabs provide the evidence.

Return to the Keycloak test application tab.

You'll still see the authenticated greeting for your user.

Return to the Account Console tab.

You'll still see the Account Console recognize myuser without another password prompt.

You closed the loop. The repaired client signs in successfully, and the same active Keycloak login works in the Account Console.

Secret mission

Discover the Provider Without the Console

Open Keycloak's built-in service directory in Firefox. Match five web addresses to jobs such as signing in, getting tokens, and signing out.

Clean Up Your Resources

Choose whether to keep the local lab running, pause it for later, or delete it entirely. The lab costs $0 aside from normal internet data usage.

Resources you used:

A Docker container running Keycloak 26.8.1 on your device.
The myrealm users, applications, and settings stored inside that container.
The downloaded Keycloak package named quay.io/keycloak/keycloak:26.8.1.

Keep everything running

No action is needed. Choose this option if you are continuing directly into Project 2.

Leave the Keycloak terminal from earlier running.
Keep the container so it retains your lab users and settings.
Keep the downloaded quay.io/keycloak/keycloak:26.8.1 package.
Reuse myrealm and myuser in Project 2.
Reuse the repaired myclient settings in Project 2.

Pause - I'll come back to this later

Stop Keycloak to free your device's memory while keeping the container. Your realm, user, and client settings remain inside the stopped container.

Return to the Keycloak terminal from earlier.
Press Ctrl+C to stop the server.
List the stopped container by running this command:

docker ps -a

What does this check show?

This check includes every container, whether running or stopped. It confirms that the Keycloak container still exists after you stop the server.

You’ll see the stopped Keycloak container listed with the quay.io/keycloak/keycloak:26.8.1 image.

Delete - I don't want to use this again

Deleting the container permanently removes all Keycloak lab state. Project 2 must recreate myrealm, myuser, and myclient if you continue later.

Return to the Keycloak terminal from earlier.
Press Ctrl+C to stop the server.
List every container by running this command:

docker ps -a

Why list containers first?

The list lets you identify the stopped lab container before deleting it. The image column distinguishes it from other containers on your device.

Find the row whose image is quay.io/keycloak/keycloak:26.8.1.
Copy the container ID from that row into <container-id>.
Remove the stopped Keycloak container by running this command:

docker rm [[CONTAINER_ID="<container-id>"]]

What does this remove?

This removes the stopped Keycloak container. It also deletes the realm, user, application settings, active logins, and other lab data stored inside that container.

Confirm the Keycloak container is gone by running this command:

docker ps -a

What confirms deletion?

The Keycloak container row should now be absent. This proves the container and the lab data stored inside it are gone.

Remove the downloaded Keycloak image by running this command:

docker image rm quay.io/keycloak/keycloak:26.8.1

What does this remove?

This deletes the downloaded Keycloak package from your device. A future lab must download it again before Keycloak can start.

Cleanup complete. The Keycloak container and its downloaded package are no longer on your device.

Docker Engine remains installed as a reusable system tool.

Nice Work!

You did it! Your local Keycloak lab now signs a user into a test application without giving that application the password. You completed Project 1 of the identity and access pathway.

What you learned:

Created a separate sign-in workspace called myrealm. You added myuser and confirmed that the username and lab password work.
Connected a test application to Keycloak. You watched the browser visit Keycloak for sign-in and return with a greeting, while the application never handled the password.
Tested sign-in safety and reuse. You saw Keycloak block an unapproved return address, repaired it, reused one login across two applications, and learned the jobs of the three token types.
Secret Mission: Opened Keycloak's service directory and matched five addresses to jobs such as signing in, getting tokens, checking user details, and signing out.

Ready to quiz yourself?