Authentication Flow

This document provides an overview of the authentication setup and login flow in TUMApply, using Keycloak and OAuth 2.0 / OIDC.

🔗 Overview

TUMApply uses Keycloak as an identity provider. The client authenticates via OAuth 2.0 and obtains a JWT token. This token is sent with each request and validated by the Spring Boot server.

• A TUM login realm called tumidpldap

• An external login realm called external-login

• A public client called tumapply-client

• Test users with password login:

  Realm	Username	Password	Role
  tumidpldap	admin1	admin	ADMIN
  tumidpldap	professor1	professor	PROFESSOR
  tumidpldap	professor2	professor	PROFESSOR
  tumidpldap	employee1	employee	EMPLOYEE
  tumidpldap	employee2	employee	EMPLOYEE
  external-login	applicant1	applicant	APPLICANT
  external-login	applicant2	applicant	APPLICANT
  external-login	applicant3	applicant	APPLICANT

These users can authenticate with a password and receive a valid access token (JWT).

🚀 Starting Keycloak

To start Keycloak, please follow the instructions in the Keycloak Setup document.

🧠 What's in the Token?

Use jwt.io to inspect the decoded token.

Example decoded JWT:

{
  "preferred_username": "admin1",
  "given_name": "Admin",
  "family_name": "One",
  ...
}

🔐 Authorization Flow in Application

• Client sends Authorization: Bearer <token> in every request
• Server extracts and validates the token, retrieves user info like preferred_username, given_name, family_name, ...

info

The user's role is not synced from Keycloak, but instead assigned and managed inside the TUMApply database.

✅ Summary

• Keycloak manages authentication, but not roles.
• User data is stored and managed in the TUMApply database.
• On first login, a new user is created with default role.