{"id":24866,"date":"2024-02-13T10:53:54","date_gmt":"2024-02-13T09:53:54","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/oauth2-with-spring-angular-keycloak-spring-for-resource-server\/"},"modified":"2024-05-16T23:26:25","modified_gmt":"2024-05-16T21:26:25","slug":"oauth2-with-spring-angular-keycloak-spring-for-resource-server","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/oauth2-with-spring-angular-keycloak-spring-for-resource-server\/","title":{"rendered":"OAuth 2 with Spring, Angular, Keycloak – Spring for Resource Server"},"content":{"rendered":"

1. Intro<\/h2>\n

This article covers the integration of OAuth2 into a Single Page Application (SPA) where Spring is the backend and Angular is the frontend. Keycloak, the common choice in the Java ecosystem, will take over the role of the Authorization server.<\/p>\n

The reader is not required to know about OAuth2 but should be familiar with Spring and Angular.<\/p>\n

OAuth2 is a de facto standard on how to authorize users. Bluntly put, authorization means that the application knows what the user is allowed to do and what not.<\/p>\n

To know with whom the application is communicating, the user authenticates themselves.<\/p>\n

From the specification perspective, it is a wrong statement, but in practice, we use OAuth2 quite often for both authentication and authorization.<\/p>\n

This complete walkthrough will explain the setup of Keykloak and the necessary implementation in Spring and Angular.<\/p>\n

The OAuth2 standard provides different constellations depending on the context. For example, mobile applications require a different setup than a Micro-Services architecture.<\/p>\n

We will follow the current best practices as of OAuth 2.1, which is still in a draft version at the time of this writing.<\/p>\n

2. OAuth 2 in a Nutshell<\/h2>\n

OAuth 2 differentiates between different roles. In our use case, Spring takes on the Resource Server role. The main OAuth 2 communication happens between Angular and Keycloak. Angular's OAuth 2 role name is "Client" and Keycloak is the "Authentication Server".<\/p>\n

As "Client", Angular's task is to initiate the authorization. It sends the end user to Keycloak and includes some metadata so that Keycloak knows from which client the user came.<\/p>\n

Keycloak provides a login screen to the user where they type in their credentials. This has the nice side effect, that neither Angular nor Spring need to know or store the credentials. Also, the user must consent to allowing the client to act on their behalf.<\/p>\n

After a bit of "chit-chat" between Angular and Keyckloak, the Angular client finally receives an access token that allows to talk with the resource server on behalf of the user. However, the Acess Token does not inform the client about the user. <\/p>\n

For this reason, OpenId Connect (OIDC) was defined. It runs on top of OAuth 2, and Keycloak provides the client with user information by also issung an Id Token. It's a JSON Web Token (JWT) that contains so called "claims".<\/p>\n

That "chit-chat" is everything else casual but highly standardized and has security concerns as a top priority. As daunting as it might be, never implement this flow on your own, but use - as in this article - the authorization server's built-in library or an OAuth2-validated generic library like https:\/\/github.com\/manfredsteyer\/angular-oauth2-oidc<\/a><\/a>.<\/p>\n

In a further article, we discuss how to increase security by using OAuth 2, OIDC and the issued tokes only at the server-side behind a Gateway<\/a>.<\/p>\n

Whenever Angular sends an HTTP request to Spring, it adds the JWT to the HTTP header. Spring parses the JWT and maps it into Spring Security. Spring has to be aware and needs to trust the Keycloak server. Therefore, Spring fetches the public key or keyset from Keycloak and uses them to verify that the signature of the JWT is valid. As it is common in asymmetric encryption, Keycloak signs every JWT with its private key.<\/p>\n

3. Keycloak Setup<\/h2>\n

3.1. Realms<\/h3>\n

The fastest way to run Keycloak is to use Docker. This would be the content for docker-compose.yml<\/strong>, which starts Keycloak with an admin user eternal<\/strong> and password eternal123<\/strong>.<\/p>\n

oauth2:\n  image: quay.io\/keycloak\/keycloak:22.0.5\n  command:\n    - start-dev\n  environment:\n    - KEYCLOAK_ADMIN=eternal\n    - KEYCLOAK_ADMIN_PASSWORD=eternal123\n  ports:\n    - "8081:8080"<\/code><\/pre>\n
An alternative is to start it directly from the command line:<\/p>\n
docker run -it -p "8081:8080" -e 'KEYCLOAK_ADMIN=eternal' -e 'KEYCLOAK_ADMIN_PASSWORD=eternal123' quay.io\/keycloak\/keycloak:21.0.2 start-dev<\/code><\/pre>\n
Navigate to http:\/\/localhost:8081\/admin<\/a><\/a>. You should see Keycloak's login screen. Enter eternal<\/strong> as username and eternal123<\/strong> as password. This should lead you to the Administration UI.<\/p>\n
\"Keycloak<\/p>\n
Keycloak Login<\/em><\/p>\n
\"Admin<\/p>\n
Keycloak Admin Screen<\/em><\/p>\n
The dropdown in the top left shows a list of existing realms. You see that as isolated instances of Keycloak with their own users, claims, etc.<\/p>\n
If you are familiar with databases, it is the same concept. You run one Oracle, SQL Server, etc., and can set up multiple databases.<\/p>\n
Click on the Realm's dropdown and create a new realm named "eternal."<\/p>\n
3.2. Client Setup<\/h3>\n
To create a new client, select "Clients" from the menu. The Client Type should show "OpenID Connect" as the default value in the form. That's what we need.<\/p>\n
The second mandatory field is the client ID. You can choose whatever you find fit. In our use case, we decided to use "eternal."<\/p>\n
\"Client<\/p>\n
Client Setup 1<\/em><\/p>\n
In the second step, we need to provide detailed information. We disable "Client authentication." This is an OIDC setting under the name "public access type." That means that as the client and running in a browser, Angular can directly communicate with Keycloak.<\/p>\n
"Direct access grants" is disabled. This setting would allow Angular to ask for the username and password and send it to Keycloak. Angular should never possess these credentials. That is also in accordance with the "OAuth2 Best Practices".<\/p>\n
We can leave the rest of the form fields as they are. So, there is no "Implicit Flow" or "OAuth 2.0 Device Authorization grant". These are settings which increase the risk of a security breach.<\/p>\n
\"Client<\/p>\n
Client Setup 2<\/em><\/p>\n
Next, we define the URL of Angular. Since Angular sends the user to Keycloak and Keycloak should send the user back to Angular, we will use "http:\/\/localhost:4200\/<\/a><\/a>" (mind the ending slash) for both "Valid redirect URIs" and "Web origins."<\/p>\n
\"Client<\/p>\n
Client Setup 3<\/em><\/p>\n
3.3. User Setup<\/h3>\n
We create two users:<\/p>\n