DEV Community: Phase Two

Securing Angular Apps with Keycloak

pnzrr — Fri, 02 Aug 2024 21:52:26 +0000

In this article we'll be using Keycloak to quickly secure a Angular application with user management and single sign on (SSO) using the open source IAMs Keycloak for Authentication and Authorization. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.

Phase Two is a Keycloak as a Service provider enabling SaaS builders to accelerate time-to-market with powerful enterprise features like SSO, identity, and user management features. Phase Two enhances Keycloak through a variety of open-source extentions for modern SaaS use cases. Phase Two supports both hosted and on-premise deployment options.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO

If you just want to skip to the code, visit the Phase Two Angular example.

If you want to see a live example, visit the Phase Two Angular example.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Keycloak Setup Details
Rather than trying to set up a "from scratch" instance of Keycloak, we're going to short-circuit that process by leveraging a Phase Two free Keycloak starter instance. The Starter provides a free hosted instance of Phase Two's enhanced Keycloak ready for light production use cases.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Keycloak's docs provide steps for how to create an OIDC client and all the various configurations that can be introduced. Follow the steps below to create a client and get the right information necessary for app configuration.

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```

    _Web origins_ (allows for Token auth call)
    ```


    http://localhost:3000

Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Angular

INFO
We will use the Phase Two Angular example code here, but the logic could easily be applied to any existing application.

Clone the Phase Two example repo.
Open the Angular folder within /frameworks/angular.
Run npm install and then npm run start. This example leverages angular-oauth2-oidc OIDC methods.
We'll review where we configure out Keycloak instance. Open the src/app/auth.config.ts file. We will be updating a few values from the prior section where we set up our OIDC client. Taking the values from the OIDC Client Config section, set those values in the code. ```tsx

export const authCodeFlowConfig: AuthConfig = {
// Update this with the url and realm of your hosted Keycloak instance
issuer: "https://app.phasetwo.io/auth/realms/p2examples",
redirectUri: window.location.origin + "/index.html",
// Update this to the Client ID you created in the OIDC Client section
clientId: "angular",
responseType: "code",
scope: "openid profile email offline_access",
showDebugInformation: true,
};

Those are used to configure the `oauthService` in the `src/app/user/user.component.ts` file. In the constructor of the component, this is passed in.
```tsx


// ...
constructor(private oauthService: OAuthService) {
  this.oauthService.configure(authCodeFlowConfig);

  // required to initialize the client
  this.oauthService.loadDiscoveryDocumentAndTryLogin();
  this.oauthService.setupAutomaticSilentRefresh();

  this.oauthService.events
    .pipe(filter((e) => e.type === 'token_received'))
    .subscribe((_) => this.oauthService.loadUserProfile());
}

The UserActivation.component.ts file contains additional methods that will assist with the interaction of the html template. For handling login and logout, the following methods are used: ```tsx

signIn() {
return this.oauthService.initLoginFlow();
}

signOut() {
return this.oauthService.logOut();
}

while we also define additional helper methods to get user information (username, email, etc) along with raw Token values. A couple are provided below as an example.
```tsx


get userName(): string {
  const claims = this.oauthService.getIdentityClaims();
  if (!claims) return '';
  return claims['given_name'];
}

get idToken(): string {
  const token = this.oauthService.getIdToken();
  if (token) {
    return this.decodeAndStringifyToken(token);
  }
  return '';
}

Switching to the html template for the user component, src/app/user/user.component.html, we can see how the login and logout buttons are rendered. The buttons are conditionally rendered based on the user's authentication status based on the presence of the idToken. ```html

The logic using the authenticator to conditionally determine the Authenticated state, can be used to secure routes, components, and more.
1. Open [localhost:4200](http://localhost:4200). You will see the Phase Two example landing page. You current state should be **Not authenticated**. Click **Log In**. This will redirect you to your login page.
> **INFO**
Use the non-admin user created in the previous section to sign in.

1. Enter the credentials of the non-admin user you created. Click **Submit**. You will then be redirected to the application. The Phase Two example landing page now loads your **Authenticated** state, displaying your user's email and name.
12. Neat! If you clear the browser state for that tab, then you will have to be redirected away to sign-in again.

## Learning more

Phase Two's enhanced Keycloak provides many ways to quickly control and tweak the log in and user management experience. Our [blog](https://phasetwo.io/blog) has many use cases from [customizing login pages](https://phasetwo.io/blog/customizing-login-pages), setting up [magic links](https://phasetwo.io/blog/set-up-magic-links) (password-less sign in), and [Organization](https://phasetwo.io/product/organizations) workflows.

Securing an Angular and Spring Boot Application with Keycloak

pnzrr — Wed, 22 May 2024 02:46:48 +0000

Spring Boot is a open-source tool which uses Java-based frameworks for building web applications.

In this article we'll be using Keycloak to secure an Angular application and access secured resources from a Spring Boot Web application.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO

If you just want to skip to the code, visit the Phase Two Spring Boot example. We are also building Keycloak examples for other frameworks.

Setting up a Spring Boot project

In order to setup a Spring Boot project, a JDK version must be chosen. As of the time of writing, to be inline with the latest changes from Keycloak 24, the Java 17 baseline will be used. Other JDK versions can also be used for developing the resource server according to the preference of the developer.

Starting with Spring Boot 2.x the Keycloak client adapters were deprecated. In Spring Boot 3.x we will use native functionalities of the spring-boot-oauth2-resource-server to be able to configure the application security context.

Quick Start

To get this project up and running locally on your computer you can clone the Phase Two Spring Boot example or follow the instructions below to generate a project from scratch.

Set up the Spring Boot project.

To kickstart a project, we will use (and recommend) using the Spring Boot Initializr, a Web-based tool that provides a simple UI to generate the project.

Provide the following values to spring initializr for the project metadata:

   Group: com.example
   Artifact: spring-boot-keycloak
   Name: spring-boot-keycloak
   Description: Demo project for Spring Boot
   Package name: com.example.spring-boot-keycloak

Add the required dependencies in spring initializr.

For the purpose of this project we will add the following dependencies:

Oauth2 Resource Server
Spring Web
Spring Security

This will result in the following lines within build.gradle.

   implementation 'org.springframework.boot:spring-boot-starter-security'
   implementation 'org.springframework.boot:spring-boot-starter-web'
   implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'

Generate the project with those settings. Open the .zip in your preferred text editor.

Setup JDK 17 for the project. Follow instructions on the JDK setup page.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Install and configure Spring Boot

Now that we've setup and configured Keycloak using Phase Two and cloned or created our Spring Boot application template, we will need to configure the project to leverage the capabilities provided by Keycloak.

Configure application settings

Update your application.yaml configuration file with the Keycloak security configuration (it's possible your download includes a application.properties file instead).

   spring:
     application:
       name: spring-boot-keycloak
     security:
       oauth2:
         resourceserver:
           jwt:
             issuer-uri: $http-keycloak-url/auth/realms/$your-realm
             jwk-set-uri: ${spring.security.oauth2.resourceserver.jwt.issuer-uri}/protocol/openid-connect/certs

Replace

$http-keycloak-url with the Keycloak URL from the Phase Two hosted Keycloak instance.
$your-realm with the Keycloak realm created earlier in this tutorial.

If you are using the local Keycloak instance from the cloned example, use the local address for $http-keycloak-url.

The below Java code omits any imports, reference our example for necessary imports or use your text editor to assist with populating the imports.

Configure Spring Boot resource server

Under src.main.java.com.springbootkeycloak create a new package, config, and create a class SecurityConfig.java. In this class, add the HttpSecurity settings:

   @Configuration
   @EnableWebSecurity
   @EnableMethodSecurity
   public class SecurityConfig {

       private final JwtClaimsConverter jwtAuthConverter;

       public SecurityConfig(JwtClaimsConverter jwtAuthConverter) {
           this.jwtAuthConverter = jwtAuthConverter;
       }

       @Bean
       public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
           http.authorizeHttpRequests(authz ->
                   authz
                           .requestMatchers("/api/**")
                           .authenticated()
           );
           http.oauth2ResourceServer(oauth2ResourceServer ->
                   oauth2ResourceServer.jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthConverter))
           );
           http.csrf(AbstractHttpConfigurer::disable);

           http.sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));
           return http.build();
       }
   }

This configuration will make the Spring Boot act as an OAuth2 Resource Server's with JWT authentication. This configuration is part of the functionality provided by the spring-boot-starter-oauth2-resource-server dependency. Read more about it's configuration here.

Add JWT token convert configuration

In the same config package, create another class, JwtClaimsConverter.java. Add a converter for extracting the security context attributes from the access_token received from Keycloak.

   @Component
   public class JwtClaimsConverter implements Converter<Jwt, AbstractAuthenticationToken> {

       @Override
       public AbstractAuthenticationToken convert(Jwt jwt) {
         var authorities = extractRealmRoles(jwt);
           return new JwtAuthenticationToken(jwt, authorities, getPrincipalFromClaim(jwt));
       }

       private String getPrincipalFromClaim(Jwt jwt) {
           var claimName = "preferred_username";
           return jwt.getClaim(claimName);
       }

       private Collection<GrantedAuthority> extractRealmRoles(Jwt jwt) {
           Map<String, Object> resource = jwt.getClaim("realm_access");
           Collection<String> roles;
           if (resource == null
                   || (roles = (Collection<String>) resource.get("roles")) == null) {
               return Set.of();
           }
           return roles.stream()
                   .map(role -> new SimpleGrantedAuthority("ROLE_" + role))
                   .collect(Collectors.toSet());
       }
   }

The provided example uses the preferred_username claim for populating the principal of the security context and the realm_access.roles to populate the authorities.

This configuration is part of the functionality provided by the spring-boot-starter-oauth2-resource-server dependency. Read more about it's configuration here.

Create the secured API resources:

In src.main.java.com.springbootkeycloak create a new package, web, and create a new class TestController.java.

To test the security integration two resource endpoints are defined:

/api/test/anonymous
/api/test/user

Implemented with this code:

   @RestController
   @RequestMapping("/api/test")
   public class TestController {

       @RequestMapping(value = "/anonymous", method = RequestMethod.GET)
       public ResponseEntity<String> getAnonymous() {
           return ResponseEntity.ok("Hello Anonymous");
       }

       @PreAuthorize("hasRole('ROLE_user')")
       @RequestMapping(value = "/user", method = RequestMethod.GET)
       public ResponseEntity<String> getUser()
       {
           return ResponseEntity.ok("Hello Secured with user role.");
       }
   }

Because both endpoints have the prefix /api they will require a secure context in order to access them. Furthermore, the /api/test/user endpoint is secured using a predefined authority ROLE_user. This is a Realm role that can be created and applied to your example user from earlier in this tutorial.

This logic can be used to extend access and authorization to any part of the application.

Start the application running with ./gradlew bootRun.

Testing the secured endpoints

The secured endpoints can be tested using curl with the Authorization header. The Authorization header must contain the access_token.

curl --location 'http://localhost:8080/api/test/anonymous' \
    --header 'Authorization: Bearer {{$access_token}}'

curl --location 'http://localhost:8080/api/test/user' \
    --header 'Authorization: Bearer {{$access_token}}'

To generate an access token, you can use the openid-connect/token endpoint from Keycloak.

curl -X POST \
  --location "https://$http-keycloak-url/auth/realms/$keycloak-realm/protocol/openid-connect/token" \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=$test-user&password=$password&grant_type=password&client_id=$client-name&client_secret=$client-secret'

Substitute the values from your Keycloak instance and test user for $http-keycloak-url, $keycloak-realm, $test-user, $password, $client-name, and $client-secret.

In the returned HTTP response, the access_token will be present. Use this token to test the secured endpoints in the example curl's above.

At this point, your Spring Boot application is secured with Keycloak, but there is no "Frontend" to the application. In the next section, we will add an Angular SPA to demonstrate sign-in with Keycloak.

Integration with Angular

In order to access the secured resources of the Spring Boot server, we will create a client application which will authenticate our users. After Authentication, that user will then have access to the secured resources via their JWT token.

Generate Angular Application

Our Spring Boot example already has a basic Angular application setup. We will use that for the rest of this setup.

In the example folder, open the angularclient folder.

If you do want to start your own Application, follow the instructions below:

Setup a new Angular application following these instructions
Use the Angular Oauth2 OIDC library to integrate authentication and authorization.

Securing views

In the /angularclient/src/app folder, the app.module.ts file is the entry point for the Angular application. The Angular application will need to be configured in order to access user information only after authentication.

@NgModule({
  declarations: [
    AppComponent,
    MainpageComponent
  ],
  imports: [
    BrowserModule,
    AppRoutingModule,
    FormsModule,
    HttpClientModule,
    OAuthModule.forRoot()
  ],
  providers: [
    {
      provide: APP_INITIALIZER,
      useFactory: applicationInitializerFactory,
      deps: [OAuthService],
      multi: true
    },
    {provide: LOCAL_STORAGE_TOKEN, useFactory: localStorageFactory},
    {provide: OAuthStorage, useFactory: localStorageFactory}
  ],
  bootstrap: [AppComponent]
})
export class AppModule {...}

The app is initialized with the OAuthService as a dependency. Tokens from the OAuthService are stored in the browser's localStorage.

To configure the OAuthService's authorization code login flow with the angular-oauth2-oidc library add the following configuration:

function configure() {
  oauthService.configure({
    // URL of the SPA to redirect the user to after login
    redirectUri: window.location.origin + "/index.html",
    // The SPA's id. The SPA is registered with this id at the auth-server
    clientId: "$your-public-keycloak-client",
    // set the scope for the permissions the client should request
    scope: "openid",
    // url for  /.well-known/openid-configuration endpoint
    issuer: "http://$http-keycloak-url:8888/auth/realms/$your-keycloak-realm",
    disablePKCE: true,
    //initialize the code flow
    responseType: "code",
    showDebugInformation: true,
  });
}

Replace http-keycloak-url, $your-public-keycloak-client, and $your-keycloak-realm with your actual Keycloak configurations.

Start the application with npm run start

User Authentication

In the user.component.html file, we authenticate the user to the logged in state and conditionally render the login and logout buttons.

<div *ngIf="isLoggedIn">
  <!-- Content for logged-in users -->
  <div class="mb-2 text-p2blue-700 text-2xl">Authenticated</div>
  <div class="mb-6 text-p2blue-700 text-md">
    <div *ngIf="userInfo">
      <p><span class="font-bold">Username</span>: {{ userInfo.username }}</p>
      <p><span class="font-bold">Email</span>: {{ userInfo.email }}</p>
      <p><span class="font-bold">Roles</span>: {{ userInfo.roles }}</p>
    </div>
  </div>
  <button [class]="buttonClasses" (click)="signOut()">Sign Out</button>
</div>
<div *ngIf="!isLoggedIn">
  <div class="mb-6 text-p2blue-700 text-2xl">Not authenticated.</div>
  <button [class]="buttonClasses" (click)="signIn()">Sign In</button>
</div>

the isLoggedIn function can be found in the user.component.ts file.

this.isLoggedIn = this.oauthService.hasValidAccessToken();

Clicking the Log In or Log Out buttons will redirect to the Keycloak login page or log the user out.

Use Angular guards to secure routes

We can achieve route restriction by using guards. If the access token is not valid the guard will initiate the login flow. You could optionally apply this at the router level to enforce a full page login.

export class AuthGuard implements CanActivate {

  constructor(private oauthService: OAuthService) {
  }

  canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean | UrlTree>{
    if(!this.oauthService.hasValidAccessToken()) {
      this.oauthService.initLoginFlow();
    }
    return of(true);
  }
}

Learning more

Phase Two's enhanced Keycloak provides many ways to quickly control and tweak the log in and user management experience. Our blog has many use cases from customizing login pages, setting up magic links (password-less sign in), and Organization workflows.

Securing SvelteKit Apps with Keycloak

pnzrr — Tue, 07 May 2024 03:02:59 +0000

Svelte and specifically, SvelteKit is an open source web framework that makes developing web applications easier.

In this article we'll be using Keycloak to quickly augment an application with user management and SSO. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two SvelteKit example.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a SvelteKit Project

INFO
We will use the Phase Two SvelteKit example code here, but the logic could easily be applied to any existing application.

Clone the Phase Two example repo.
Open the SvelteKit folder within /frameworks/sveltekit.
Run npm install and then npm run dev. This example leverages @auth/sveltekit to provide HOC support.
The project makes use of the following SvelteKit items: hooks, components, layout, and @auth/sveltekit module. We'll review each in kind.
We'll review where we configure out Keycloak instance. Open the src/auth.ts file. This is a server only file. We will be updating a few values from the prior section where we set up our OIDC client. Taking the values from the OIDC Client Config section, set those values in the code. While it is recommended to use Environment variables for the secret, for the purpose of this tutorial, paste in the Client secret from the OIDC client creation section for the value of clientSecret.

// Use Environment Variables AUTH_SECRET in prod
const authjsSecret =
  "f18d48ce9bea32e44b5591b2c89185729d4559435f77ca76872a83a0850563a4";

const realm = "shared-deployment-001";

const kcConfig = {
  // Use Environment Variables AUTH_KEYCLOAK_ISSUER in prod
  issuer: `https://usw2.auth.ac/auth/realms/${realm}`,
  // Paste "Client id" here. Use Environment Variables AUTH_KEYCLOAK_ID in prod
  clientId: "reg-example-1",
  // Paste "Client secret" here. Use Environment Variables AUTH_KEYCLOAK_ISSUER in prod
  clientSecret: "CLIENT_SECRET",
};

Those are used to popluate the config for the provider Keycloak:

export const { handle, signIn, signOut } = SvelteKitAuth({
  trustHost: true,
  secret: authjsSecret,
  providers: [Keycloak(kcConfig)],
});

Next, let's review the hooks (src/hooks.server.ts) file. This imports the handle method by the src/auth.ts and re-exports it. This allows the hooks to act as a middleware and include the authentication status of the user in each request.

export { handle } from "./auth.js";

To retrieve the authentication status of the user in server-side rendering on the index route, it's using the +layout.server.ts file. It retrieves the authentication status via the getSession function from SvelteKit Locals set by src/hook.server.ts.

import type { LayoutServerLoad } from "./$types.js";

export const load: LayoutServerLoad = async (event) => {
  const session = await event.locals.getSession();
  return {
    session,
  };
};

The server-side authentication data is then accessed inside the +page.svelte, and then passed onto the user (src/components/user.svelte) component as follows:

<script lang="ts">
  import User from "$components/user.svelte";
  import type { LayoutServerData } from "./$types.js";

  export let data: LayoutServerData;
</script>

// ... Rest of the index route ... // <User data={{ user: data?.session?.user,
status: Boolean(data?.session), }} />

The props, user and status represent the user information object and whether the user is signed in, respectively.

At this point our entire application will be able to access all information and methods needed to perform authentication. View src/components/user.svelte for exactly how the code is authenticating your user. The sections rendering the Log in and Log out buttons are conditional areas based on the authenticated context. The buttons invoke server-side APIs provided by @auth/sveltekit.

The logic using the authenticator to conditionally determine the Authenticated state, can be used to secure routes, components, and more.

Open localhost:3000. You will see the Phase Two example landing page. You current state should be Not authenticated. Click Log In. This will redirect you to your login page.

INFO
Use the non-admin user created in the previous section to sign in.

Enter the credentials of the non-admin user you created. Click Submit. You will then be redirected to the application. The Phase Two example landing page now loads your Authenticated state, displaying your user's email and name.
Neat! If you clear the browser state for that tab, then you will have to be redirected away to sign-in again.

Learning more

Securing Remix Apps with Keycloak

pnzrr — Tue, 07 May 2024 02:45:41 +0000

Remix is an open source web framework that makes developing web applications easier.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two Remix example. We also have a plain React example.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a Remix Project

INFO
We will use the Phase Two Remix example code here, but the logic could easily be applied to any existing application.

Clone the Phase Two example repo.
Open the Remix folder within /frameworks/remix.
Run npm install and then npm run dev -- --port 3000. This example leverages remix-auth and remix-keycloak to provide HOC support.
Open the app/services/keycloak.server.ts file. This is a server only file. We will be updating a few values from the prior section where we set up our OIDC client. Taking the values from the OIDC Client Config section, set those values in the code. While it is recommended to use Environment variables for the secret, for the purpose of this tutorial, paste in the Client secret from the OIDC client creation section for the value of clientSecret:

const kcConfig = {
  useSSL: true,
  domain: "usw2.auth.ac/auth",
  realm: "shared-deployment-001",
  clientID: "reg-example-1",
  clientSecret: "CLIENT_SECRET", // Paste "Client secret" here. Use Environment variables in prod
  callbackURL: "http://localhost:3000/auth/keycloak/callback",
};

Those are used to popluate the config for the KeycloakStrategy:

export default new KeycloakStrategy(kcConfig, ({ profile }) => profile);

The config is then used with the Authenticator instance in the app/services/auth.server.ts file. The authenticator instance uses the Session Storage to manage the state of authentication via a cookie.

import { Authenticator } from "remix-auth";
import keycloakServer from "./keycloak.server";
import { sessionStorage } from "~/services/session.server";

export const authenticator = new Authenticator(sessionStorage);

authenticator.use(keycloakServer);

At this point our entire application will be able to access all information and methods needed to perform authentication. View the session.server.ts file for additional information about how the SessionStorage is used. The SessionStorage stores the Keycloak token and is used to derive the authenticated state. View user.tsx for exactly how the code is authenticating your user. The sections rendering the Log in and Log out buttons are conditional areas based on the authenticated context. The buttons invoke server-side APIs provided by remix-auth.

The logic using the authenticator to conditionally determine the Authenticated state, can be used to secure routes, components, and more.

Open localhost:3000. You will see the Phase Two example landing page. You current state should be Not authenticated. Click Log In. This will redirect you to your login page.

INFO
Use the non-admin user created in the previous section to sign in.

Enter the credentials of the non-admin user you created. Click Submit. You will then be redirected to the application. The Phase Two example landing page now loads your Authenticated state, displaying your user's email and name.
Neat! If you clear the browser state for that tab, then you will have to be redirected away to sign-in again.

Learning more

User Management and Identity Brokering for On-Prem Apps with Keycloak

pnzrr — Wed, 03 Apr 2024 02:39:34 +0000

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

User Management and Identity Brokering for On-Prem Apps

With many companies racing into the cloud, very little is written about the huge opportunity, and potential pitfalls of building software for on-prem and private cloud deployments. With the growing Kubernetes and CNCF ecosystems, the balance point to justify self-hosting is constantly shifting. This is great news for companies that must host data and applications inside the enterprise. For software vendors looking to serve this exploding market, authentication can be a blind spot.

A story, inspired by customer use cases:

You’ve built a successful enterprise SaaS product, and your cloud offering has taken off. Recently, you’ve been getting inquiries from government agencies, large companies in regulated industries, and foreign companies – all of which have legal, compliance or regulatory requirements that prohibit them from using your product in the cloud.

Given the size of the opportunity, you’ve decided to go for it. Your team has packaged your application up as a set of Kubernetes manifests, making changes, replacing cloud services with open source alternatives, and even built out a runbook to help your devops peers at the customer operate it themselves.

The big day comes, and you’re installing at your first customer. You expect that there will be some minor bumps along the way, but their first question just flattens you: “How do we connect this to our in-house identity provider?” It was a question that was never on your radar, but now it’s the most important thing for the customer.

Like most SaaS companies, you’re probably either hand-rolling your authentication and user management using something like Passport.js, Devise, Django, etc., using some social login options, or using a cloud-only service like Auth0 or WorkOS. If you had implemented SAML, the most common protocol for just-in-time user provisioning with enterprise identity providers, you probably went for a basic approach. You wrongly assumed that user management and identity brokering would be easier for on-prem.

You throw some engineering and customer success resources at the problem, but quickly realize it’s not a scalable solution. The customer wants to map their groups, and manage access and authorization through their IdP. Just the overhead of connecting to every possible type of IdP, and supporting that for every customer, will eat up your margin before they start using your application.

The good news is that you’re not alone in missing this key enterprise need. Many companies who are new to on-prem and private cloud deployments learn this the hard way, many without losing customers.

However, the reality is that for an application that is used by an entire enterprise, who can use it (authentication) and how (authorization) is equally as important for on-prem applications as cloud. And, being hosted and operated by your customer, simplicity of management and transparency is more important than cloud.

An open source solution to the rescue

Fortunately, there is feature complete identity and access management system that is equally at home both on-premise and in the cloud. It can easily facilitate identity brokering with the customer identity provider, as well as give their IT staff access to critical access and operational information.

At Phase Two, we’ve had a front row seat in solving this problem. Our customers have deployed Keycloak, bundled with their application to over 300 of their customer sites. In these deployments, Keycloak is used for identity brokering to the customer identity provider, SSO authentication for all of their deployed applications, and role and access management to broker and manage authorization within their applications.

Tools to empower the customer

In addition to solving these core challenges, Phase Two has built tools to extend enterprise use-cases and facilitate customer onboarding, one of the biggest drags on Customer Success hours, and ultimately a huge margin drain.

To this end, the most valuable tool, from our customers’ perspectives is our Identity Provider Setup Wizard. This tool is meant as a guide for customers’ initial IdP connection, turning an esoteric form into a clear step-by-step process for specific IDPs (what keys to get, where to store them, and so on). This had previously been the long pole in the onboarding tent. By giving the customers a tool to self-configure and manage their own IdP connection, Phase Two has gifted back valuable Customer Success hours and margin dollars.

We conveniently bundle all of these tools in Docker images for easy deployment.

Does the above story sound familiar, or something you might be stumbling into? Contact sales to find out how we can help your journey to on-prem be as painless as possible and supercharge your customer identity onboarding process.

Keycloak: An open source alternative to Auth0, WorkOS, Okta, Cognito, ...

pnzrr — Wed, 03 Apr 2024 02:33:40 +0000

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

In today's digital landscape, managing user identities and securing access to applications and services is paramount for businesses of all sizes. As the demand for robust identity and access management (IAM) solutions grows, so does the market, with various commercial options vying for attention. When we first started using Keycloak over 7 years ago, we were surprised that there was a relatively unknown, but completely open-source alternative to commercial offerings in the Identity and Access Management market.

Commercial offerings

Companies such as Auth0, Okta, Microsoft (through AzureAD) had created cloud authentication services, and helped bring standardization to the market through implementation of standards, such as OIDC, SAML, SCIM, LDAP, etc. However, there was little differentiation among them, and despite their pricing models, were essentially commodities that were the same.

Amazon released AWS Cognito, which did price it as a commodity, but failed so miserably in UI and developer ergonomics, that it failed to reach a dominant market position despite its de minimis cost.

More recently, nascent companies such as WorkOS and Frontegg, while casting themselves as CIAM and “SSO made easy” to enterprise SaaS customers, are really just repackaging the same IAM features and protocol implementations that have been available in Keycloak for years. Furthermore, the pricing models have tilted back towards predatory on your company’s business model.

Open source alternatives

Amidst this landscape, open-source alternatives like Keycloak are emerging as powerful contenders, offering unique advantages over their commercial counterparts. Because the market has settled on standard protocols, it opened the door for superior open-source implementations to emerge with feature parity and standards compliance. Keycloak stands out as an alternative to commercial IAM solutions, enabling your business to unlock both flexibility and control.

Open Source Foundation: At the heart of Keycloak lies its open-source nature. Developed by Red Hat, Keycloak provides a fully-fledged IAM solution that is freely available for anyone to use, modify, and extend according to their requirements. This open ethos empowers organizations with unparalleled flexibility and control over their identity infrastructure, without being tied to proprietary vendors or licensing agreements. Furthermore, given the core security requirements of the protocol implementations, developing in the open gives customers the reassurance that the code has been audited by others, unlike closed source, buggy, commercial implementations that come with zero transparency or guarantees.
Cost-Effectiveness: One of the most significant advantages of Keycloak is its cost-effectiveness. Unlike commercial IAM solutions that operate on subscription-based pricing models, Keycloak eliminates licensing fees, enabling organizations to allocate resources more efficiently. With Keycloak, businesses can scale their identity infrastructure without worrying about escalating costs, making it an attractive option for startups, small businesses, and enterprises alike.
Customization and Extensibility: Keycloak stands out for its robust customization and extensibility capabilities. From authentication flows and user federation to role-based access control (RBAC) and fine-grained permissions, Keycloak provides a plethora of features that can be tailored to suit specific use cases and compliance requirements. Moreover, its modular architecture and comprehensive API support facilitate seamless integration with existing systems and third-party services, empowering developers to build bespoke identity solutions with ease.
On-Premise and Cloud Deployment: Whether organizations prefer on-premise deployment for enhanced security and compliance or cloud-based solutions for scalability and convenience, Keycloak offers the flexibility to meet diverse deployment needs. With support for Docker, Kubernetes, and other containerization technologies, Keycloak simplifies deployment across various environments, ensuring seamless integration into existing infrastructure and workflows.
Active Community and Support: Backed by a vibrant community of developers and contributors, Keycloak benefits from ongoing enhancements, bug fixes, and feature additions. This active ecosystem fosters innovation and collaboration, with users sharing best practices, troubleshooting tips, and extensions through forums, mailing lists, and code repositories. Additionally, organizations seeking professional support and services can leverage expertise of a growing ecosystem of companies providing support, ensuring reliable deployment and ongoing maintenance of their Keycloak instances.

Barriers

So, given Keycloak's inherent advantages, while solving all of the same problems, why has it failed to receive broad market adoption? Looking back, and polling our customer base, it seems that Keycloak has suffered from a couple of barriers:

Awareness: Other than a couple of markets (e.g. Germany) Keycloak is still relatively unknown. Because it’s not a commercial entity, there isn’t a content marketing engine that focuses on discovery for common use cases.
Onboarding: Documentation for getting successful for common use cases is fragmented and often hard to find. When solving a new problem, examples are a great way to get a developer “hooked”, but these are largely missing from official Keycloak documentation.
Community: Because the core Keycloak developers have largely been working for one customer (RedHat) and not the community at large, developers who are exploring Keycloak for the first time can find it hard to know where to ask question. While the Discourse, GitHub, Slack and mailing lists are a good direction, there’s not a definitive way to get support.
UI: The Keycloak Admin UI, while complete, is intimidating to new users. Unlike the commercial alternatives, that have invested resources in building and measuring customer success into their UIs, while Keycloak’s attitude has been "RTFM". Furthermore, the user facing UIs of Keycloak are notoriously “rough edged”, commercial alternatives are beautiful, modern, and capable of easy customization and branding.

Obviously, we think that the barriers are something that can be solved, and Phase Two has been working hard in its open source extensions and cloud offerings to overcome these barriers. We've already made great strides, and believe that we're at the point where customers can realize the above advantages, while compromising relatively little -- All while achieving tremendous cost savings.

Migrating from your current identity provider

Already using one of the commercial systems? Keycloak is a complete, robust and mature identity solution that can replace your identity provider and user management systems today. It has complete parity with all of the major features of commercial IAM systems, and because of reliance on standards, migration is easier than you think. By migrating to Keycloak, you gain full control over your authentication and authorization processes, enabling seamless integration, customization, and scalability tailored to your organization's unique needs.

Phase two has implemented user migration support in the product for all tiers. This is meant to ease your transition from your existing user management system so that migration can occur incrementally with a complete fallback plan. For Premium and Enterprise subscribers, we include migration support. Contact sales to get started with your migration.

Conclusion

In a landscape dominated by commercial IAM solutions, Keycloak shines as a compelling alternative that combines the power of open source with enterprise-grade features and flexibility. With its cost-effectiveness, customization capabilities, deployment flexibility, and active community support, Keycloak empowers organizations to take control of their identity infrastructure, unlock new possibilities, and adapt to evolving security and compliance requirements. Whether you're a startup looking to bootstrap your identity management or an enterprise seeking to streamline operations, Keycloak offers a compelling solution that puts you in the driver's seat of your IAM journey.

Securing Vue Apps with Keycloak

pnzrr — Wed, 03 Apr 2024 02:26:39 +0000

Vue.js is an open source web framework that makes developing web applications easier.

In this article we'll be using Keycloak to secure a Vue.js Web application. We're going to leverage oidc-client-ts to integrate OIDC authentication with the Vue app. The oidc-client-ts package is a well-maintained and used library. It provides a lot of utilities for building out a fully production app.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two Vue.js example. We are also building Keycloak examples for other frameworks.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a Vue.js Project

Clone the Phase Two example repo.
Open the Vue folder within /frameworks/vue and open the /nuxt/oidc-client-ts folder.
Run npm install and then npm run dev.
We'll review where we configure out Keycloak instance. First open /auth.ts. In this file you will want to update it with the values for the Keycloak instance we set-up earlier in the tutorial. Update the clientSecret with the value. Use and environment variable here if you wish.

   export const keycloakConfig = {
     authorityUrl: "https://euc1.auth.ac",
     applicationUrl: "http://localhost:3000",
     realm: "shared-deployment-001",
     clientId: "reg-example-1",
     clientSecret: "CLIENT_SECRET",
   };

After the config, you can see how the OIDC instance is started.

   const settings = {
     authority: `${keycloakConfig.authorityUrl}/auth/realms/${keycloakConfig.realm}`,
     client_id: keycloakConfig.clientId,
     client_secret: keycloakConfig.clientSecret,
     redirect_uri: `${window.location.origin}/auth`,
     silent_redirect_uri: `${window.location.origin}/silent-refresh`,
     post_logout_redirect_uri: `${window.location.origin}`,
     response_type: "code",
     userStore: new WebStorageStateStore(),
     loadUserInfo: true,
   };
   this.userManager = new UserManager(settings);

With the Keycloak instance defined, we attach this to the app instance for Vue. Switch to /main.ts

   import Auth from "@/auth";
   // ...
   app.config.globalProperties.$auth = Auth;

We pull in the Auth instance then expose it through the $auth variable.

There are a few main pages in play here that we define to create paths the library can leverage. The /view/auth and /view/silent-refresh create paths at the same name. These are used to do the redirection during authentication. From within these we use the Auth instance to direct the user around within the app. For instance in /views/AuthView:

   export default {
     name: "AuthAuthenticated",
     async mounted() {
       try {
         await this.$auth.signinCallback();
         this.$router.push("/");
       } catch (e) {
         console.error(e);
       }
     },
   };

The router.push naively sends someone to the home page. This could be updated to go to any number of places, including the page one started the login flow from if you were to store that information to be retrieved.

Now that we have all the things setup, we can define the user component /components/User to easily pull information about the user's state and display the appropriate UI.

   export default {
     name: "UserComponent",
     data() {
       return {
         user: null,
         signIn: () => this.$auth.signinRedirect(),
         logout: () => this.$auth.signoutRedirect(),
       };
     },
     async created() {
       const user = await this.$auth.getUser();
       if (user) {
         this.user = user;
       }
     },
   };

With this, the user object is now easily available. A simple v-if="user" allows the app to determine what UI to show.

Learning more

Securing Nuxt Apps with Keycloak

pnzrr — Mon, 11 Sep 2023 11:26:22 +0000

Nuxt is an open source web framework that makes developing web applications easier.

In this article we'll be using Keycloak to secure a Nuxt Web application. We will use two different methods: keycloak-js and oidc-client-ts.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two Nuxt example. We are also building Keycloak examples for other frameworks.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a Nuxt Project

INFO
We will use the Phase Two Nuxt example code here, but the logic could easily be applied to any existing application.

This example uses Nuxt3. There are a couple methods by which you can integrate Keycloak to your Nuxt application. We're going to explore two methods here, one uses keycloak-js and the other leverages oidc-client-ts. The keycloak-js library provides a simple, client-only method, but lacks some of the sophistication provided by the oidc-client library that is heavily supported and more widely used.

Using `keycloak-js`

INFO
For this example, we need to disable "Client Authentication" in the OIDC client that was setup earlier. This is available under Client > Settings > Capability config > Client authentication to OFF.

Clone the Phase Two example repo.
Open the Nuxt folder within /frameworks/nuxt and open the keycloak-js folder within /frameworks/nuxt/keycloak-js.
Run npm install and then npm run dev. keycloak-js is a Javascript library that provides a fast way to secure an application.
The project makes use of the following Nuxt items: components, composables, layouts, and plugins. We'll review each in kind.
The main component that shows the User's authenticated state is in /components/User. In this component we call the useKeycloak composable, which let's us key into the keycloak-js functions that we've wrapped to make easily availble.

   const { keycloak, authState } = useKeycloak();

   function login() {
     keycloak.login();
   }

   function logout() {
     keycloak.logout();
   }

Lower in the file the component leverages v-if checks to determine if the authState is authenticated or not. Depending on the state, a Log in or Log out button is available.

Let's take a look at the setup for the composable next. Our composable is in /composables/keycloak-c. A composable is a function defined that can be called anywhere in the Nuxt application. It's a good way to abstract logic to be reused. In our case we use it to wrap a keycloak-js plugin (more on that in the next step) and help provided a state value for the authenticated state.

   export const useKeycloak = () => {
     const nuxtApp = useNuxtApp();
     const keycloak = nuxtApp.$keycloak as Keycloak;
     const authState = useState("authState", () => "unAuthenticated");

     keycloak.onAuthSuccess = () => (authState.value = "authenticated");
     keycloak.onAuthError = () => (authState.value = "error");

     return {
       keycloak,
       authState,
     };
   };

In the plugin, /plugins/keycloak.client.ts we instantiate the keycloak-js library. We can then attach that instance to the NuxtApp instance. Substitute the correct values for your Keycloak instance that we created earlier in the tutorial.

   export default defineNuxtPlugin((nuxtApp) => {
     const initOptions: KeycloakConfig = {
       url: "https://euc1.auth.ac/auth/",
       realm: "shared-deployment-001",
       clientId: "reg-example-1",
     };

     const keycloak = new Keycloak(initOptions);

     nuxtApp.$keycloak = keycloak;

     keycloak.init({
       onLoad: "check-sso",
     });
   });

The logic for checking the authenticated state can be used to expand in ways to secure your site in a number of ways.

Using `oidc-client`

The oidc-client-ts package is a well-maintained and used library. It provides a lot of utilities for building out a fully production app.

Clone the Phase Two example repo.
Open the Nuxt folder within /frameworks/nuxt and open the /nuxt/oidc-client-ts folder.
Run npm install and then npm run dev.
The structure of the project is similar to the keycloak-js version but with a the use of services, stores, and middleware.
We'll review where we configure out Keycloak instance. First open /services/keycloak-config.ts. In this file you will want to update it with the values for the Keycloak instance we set-up earlier in the tutorial. Make sure you are using the one with Client Authentication enabled. Update the clientSecret with the value. Use and environment variable here if you wish.

   export const keycloakConfig = {
     authorityUrl: "https://euc1.auth.ac",
     applicationUrl: "http://localhost:3000",
     realm: "shared-deployment-001",
     clientId: "reg-example-1",
     clientSecret: "CLIENT_SECRET",
   };

Switch over to the /services/auth-service now to see how the Oidc instance is started. The class pulls in values from the keycloakConfig to use in the constructor. The other functions are wrappers around methods provided by the oidc-client library. This allows us to key into things like signInRedirect and signoutRedirect.

How the settings are integrated:

   const settings = {
     authority: `${keycloakConfig.authorityUrl}/auth/realms/${keycloakConfig.realm}`,
     client_id: keycloakConfig.clientId,
     client_secret: keycloakConfig.clientSecret,
     redirect_uri: `${window.location.origin}/auth`,
     silent_redirect_uri: `${window.location.origin}/silent-refresh`,
     post_logout_redirect_uri: `${window.location.origin}`,
     response_type: "code",
     userStore: new WebStorageStateStore(),
     loadUserInfo: true,
   };
   this.userManager = new UserManager(settings);

Example function wrapper:

   public signInRedirect() {
     return this.userManager.signinRedirect();
   }

With the AuthService defined, we can now expose that through a composable. Switch to the /composables/useServices file. The file is simple but provides a way for any component to hook into the service instance.

   import AuthService from "@/services/auth-service";
   import ApplicationService from "@/services/application-service";
   import { useAuth } from "@/stores/auth";

   export const useServices = () => {
     const authStore = useAuth();

     return {
       $auth: new AuthService(),
       $application: new ApplicationService(authStore.access_token),
     };
   };

We pull in the AuthService then expose it through the $auth variable. The $application variable exposes the ApplicationService which is provided as an example of how you could secure API calls.

We leverage the pinia library to make store User information to make it easily accessible. Open /stores/auth/index. From within this file, we can wrap the User object exposed by the oidc-client package. This can then be leveraged in the middleware function we want to define or to pull information quickly about the user.
There are a few main pages in play here that we define to create paths the library can leverage. The /pages/auth, /pages/logout, /pages/silent-refresh create paths at the same name. These are used to do the redirection during authentication or log out. From within these we use the AuthService to direct the user around within the app. For instance in /auth:

   const authenticateOidc = async () => {
     try {
       await services.$auth.signInCallback();
       router.push("/");
     } catch (error) {
       console.error(error);
     }
   };

   await authenticateOidc();

We have also created a middleware file in /middleware/auth.global to be used in a couple of ways. It checks if the user is authenticated and based on that knowledge, stores the user information in the store (if not there) or could be used to send someone to login. For our example, we created buttons to initiate that but there is a comment which shows how you could force a set of paths to require login.

   const authFlowRoutes = ["/auth", "/silent-refresh", "/logout"];

   export default defineNuxtRouteMiddleware(async (to, from) => {
     const authStore = useAuth();
     const services = useServices();
     const user = (await services.$auth.getUser()) as User;

     if (!user && !authFlowRoutes.includes(to.path)) {
       // use this to automatically force a sign in and redirect
       // services.$auth.signInRedirect();
     } else {
       authStore.setUpUserCredentials(user);
     }
   });

Now that we have all the things setup, we can define the user component /components/User to easily pull information about the user's state and display the appropriate UI.

   const authStore = useAuth();
   const user = authStore.user;

   const signIn = () => services.$auth.signInRedirect();
   const signOut = () => services.$auth.logout();

With this, the user object is now easily available. A simple v-if="user" allows the app to determine what UI to show.

A bit more complicated of a setup, but more elegant in the handling of the logged in flow. The oidc-client allows for much better fine-tuning of the experience.

Learning more

Django Web Authentication with Keycloak

pnzrr — Mon, 04 Sep 2023 14:50:13 +0000

Django is a high-level, open-source web framework for building web applications using the Python programming language. It follows the Model-View-Controller (MVC) architectural pattern.

In this article we'll be using Keycloak to secure a Django Web application.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two Django example. We are also building Keycloak examples for other frameworks.

Setting up a Django Project

The following could be applied to an existing Django application, but we have chosen to use the excellent tutorial application built by Mozilla as our example. If you aren't yet familiar with Django, we encourage you to follow the tutorial there.

The completed code for that tutorial is available in their GitHub repository. We'll clone it to get started.

Quick Start

To get this project up and running locally on your computer:

Set up the Python development environment. We recommend using a Python virtual environment.
Assuming you have Python setup, run the following commands (if you're on Windows you may use py or py -3 instead of python to start Python):

   pip install -r requirements.txt
   python manage.py makemigrations
   python manage.py migrate
   python manage.py collectstatic
   python manage.py test # Run the standard tests. These should all pass.
   python manage.py createsuperuser # Create a superuser
   python manage.py runserver

Open a browser to http://127.0.0.1:8000/admin/ to open the admin site
Create a few test objects of each type.
Open tab to http://127.0.0.1:8000 to see the main site, with your new objects.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to On.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details
We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.
You also need to copy the Client secret in the Credential tab for the client to use. Once on the Credential tab, click the copy button to copy the key to your clipboard. Save the key somewhere for use later in this tutorial

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Install and configure the Django OIDC library

Now that we've installed and configured Keycloak, we need to setup Django to replace the native authentication method provided by the framework. The first task is to install a library that is compatible with Keycloak's OIDC implementation.

The mozilla-django-oidc library provides an easy way to integrate Keycloak (or any OpenID Connect-compliant identity provider) with your Django app. It abstracts many of the complexities of integrating authentication and authorization. Here's how you can set it up:

Install the Package: Install the mozilla-django-oidc package using pip:

   pip install mozilla-django-oidc

Configure Django Settings: Update your Django app's settings.py to include the necessary configurations for mozilla-django-oidc:

   INSTALLED_APPS = [
       # ...
       'django.contrib.auth',
       'mozilla_django_oidc',  # Load after django.contrib.auth
       # ...
   ]

   AUTHENTICATION_BACKENDS = (
       'mozilla_django_oidc.auth.OIDCAuthenticationBackend',
       # ...
   )

   OIDC_RP_CLIENT_ID = 'your-client-id'
   OIDC_RP_CLIENT_SECRET = 'your-client-secret'
   OIDC_OP_AUTHORIZATION_ENDPOINT = 'https://keycloak-url/auth/realms/your-realm/protocol/openid-connect/auth'
   OIDC_OP_TOKEN_ENDPOINT = 'https://keycloak-url/auth/realms/your-realm/protocol/openid-connect/token'
   OIDC_OP_USER_ENDPOINT = 'https://keycloak-url/auth/realms/your-realm/protocol/openid-connect/userinfo'
   OIDC_OP_JWKS_ENDPOINT = 'https://keycloak-url/auth/realms/your-realm/protocol/openid-connect/certs'
   OIDC_RP_SIGN_ALGO = 'RS256'

   LOGIN_URL = 'oidc_authentication_init'
   LOGOUT_REDIRECT_URL = '/'
   LOGIN_REDIRECT_URL = '/'

Replace your-client-id, your-client-secret, and the Keycloak URLs with your actual Keycloak configurations.

Add URLs: Update your Django app's urls.py to include the authentication URLs provided by mozilla-django-oidc:

   urlpatterns += [
       path('oidc/', include('mozilla_django_oidc.urls')),
   ]

Using it in your app

Protect your views

Use Decorators for Access Control. You can now use the @oidc_protected decorator to protect views that require authentication and potentially specific roles:

from mozilla_django_oidc.decorators import oidc_protected

@oidc_protected
def protected_view(request):
    # Your view logic

Accessing user information

You can access user information after authentication using the request.oidc_user attribute. For example:

def profile_view(request):
    user_info = request.oidc_user.userinfo
    # Access user_info['sub'], user_info['email'], etc.
    # Your view logic

By default, mozilla-django-oidc looks up a Django user matching the email field to the email address returned in the user info data from Keycloak.

If a user logs into your site and doesn’t already have an account, by default, mozilla-django-oidc will create a new Django user account. It will create the User instance filling in the username (hash of the email address) and email fields.

Use Username rather than Email

mozilla-django-oidc defaults to setting up Django users using the email address as the user name from keycloak was required. Fortunately, preferred_username is set up by default in Keycloak as a claim. The claim can used by overriding the OIDCAuthenticationBackend class in mozilla_django_oidc.auth and referring to this in AUTHENTICATION_BACKENDS as below:


# Classes to override default OIDCAuthenticationBackend (Keycloak authentication)
from mozilla_django_oidc.auth import OIDCAuthenticationBackend

class KeycloakOIDCAuthenticationBackend(OIDCAuthenticationBackend):

 def create_user(self, claims):
     """ Overrides Authentication Backend so that Django users are
         created with the keycloak preferred_username.
         If nothing found matching the email, then try the username.
     """
     user = super(KeycloakOIDCAuthenticationBackend, self).create_user(claims)
     user.first_name = claims.get('given_name', '')
     user.last_name = claims.get('family_name', '')
     user.email = claims.get('email')
     user.username = claims.get('preferred_username')
     user.save()
     return user

 def filter_users_by_claims(self, claims):
     """ Return all users matching the specified email.
         If nothing found matching the email, then try the username
     """
     email = claims.get('email')
     preferred_username = claims.get('preferred_username')

     if not email:
         return self.UserModel.objects.none()
     users = self.UserModel.objects.filter(email__iexact=email)

     if len(users) < 1:
         if not preferred_username:
             return self.UserModel.objects.none()
         users = self.UserModel.objects.filter(username__iexact=preferred_username)
     return users

 def update_user(self, user, claims):
     user.first_name = claims.get('given_name', '')
     user.last_name = claims.get('family_name', '')
     user.email = claims.get('email')
     user.username = claims.get('preferred_username')
     user.save()
     return user

In settings.py, overide the new library you have just added in AUTHENTICATION_BACKENDS :

 # mozilla_django_oidc - Keycloak authentication
 "fragalysis.auth.KeycloakOIDCAuthenticationBackend",

Logging out

You can use the @oidc_logout decorator to log the user out of both your app and Keycloak:

from mozilla_django_oidc.decorators import oidc_logout

@oidc_logout
def logout_view(request):
    # Your logout view logic

Add support for Django Rest Framework

Django Rest Framework (DRF) is a flexible toolkit built on top of Django, specifically designed for building RESTful APIs.

If you want DRF to authenticate users based on an OAuth access token provided in the Authorization header, you can use the DRF-specific authentication class which ships with the package.

Add this to your settings:

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'mozilla_django_oidc.contrib.drf.OIDCAuthentication',
        'rest_framework.authentication.SessionAuthentication',
        # other authentication classes, if needed
    ],
}

Note that this only takes care of authenticating against an access token, and provides no options to create or renew tokens.

If you’ve created a custom Django OIDCAuthenticationBackend and added that to your AUTHENTICATION_BACKENDS, the DRF class should be smart enough to figure that out. Alternatively, you can manually set the OIDC backend to use:

OIDC_DRF_AUTH_BACKEND = 'mozilla_django_oidc.auth.OIDCAuthenticationBackend'

Learning more

Securing a Next.js Application with Keycloak

pnzrr — Wed, 16 Aug 2023 03:28:27 +0000

In this article, we'll be using Keycloak to quickly augment an application with user management and SSO. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two Next.js example. We also have a plain React example.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to On.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details
We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.
You also need to copy the Client secret in the Credential tab for the client to use. Once on the Credential tab, click the copy button to copy the key to your clipboard. Save the key somewhere for use later in this tutorial

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a Next.js Project

INFO
We will use the Phase Two Next.js example code here, but the logic could easily be applied to any existing application.

This example uses Next.js 13 and splits server and client components accordingly.

Clone the Phase Two example repo.
Open the Next.js folder within /frameworks/nextjs.
Run npm install and then npm run dev. This example leverages NextAuth.js to provide hook and HOC support.
NextAuth.js configures an API route that is uses for the Authentication of the Client. It generates the routes automatically for you. These are added to Next.js in the api/auth/[...nextauth]/route.ts file.
Open the src/lib/auth.ts file. This is a server only file. We will be updating a few values from the prior section where we set up our OIDC client. Taking the values from the OIDC Client Config section, set those values in the code. While it is recommended to use Environment variables for the secret, for the purpose of this tutorial, paste in the Client secret from the OIDC client creation section for the value of clientSecret

const authServerUrl = "https://euc1.auth.ac/auth/";
const realm = "shared-deployment-001";
const clientId = "reg-example-1";
const clientSecret = "CLIENT_SECRET"; // Paste "Client secret" here. Use Environment variables in prod

Those are used to popluate the AuthOptions config for the KeycloakProvider:

export const AuthOptions: NextAuthOptions = {
  providers: [
    KeycloakProvider({
      clientId,
      clientSecret,
      issuer: `${authServerUrl}realms/${realm}`,
    }),
  ],
};

The config is then provided to the AuthProvider in the /src/app/layout.tsx file. Next.js uses this file to generate an HTML view for this page.

import { NextAuthProvider as AuthProvider } from "./providers";
...
<AuthProvider {...oidcConfig}>
  <App />
</AuthProvider>

At this point, our entire application will be able to access all information and methods needed to perform authentication. View the providers.tsx file for additional information about how the SessionProvider is used. The SessionProvider enables use of Hooks to derive the authenticated state. View user.component.tsx for exactly how the code is authenticating your user. The sections rendering the "Log in" and "Log out" buttons are conditional areas based on the authenticated context. The buttons invoke functions provided by NextAuth.

The logic using the hook to conditionally determine the Authenticated state, can be used to secure routes, components, and more.

Open localhost:3000. You will see the Phase Two example landing page. You current state should be "Not authenticated". Click Log In. This will redirect you to your login page.

INFO
Use the non-admin user created in the previous section to sign in.

Enter the credentials of the non-admin user you created. Click Submit. You will then be redirected to the application. The Phase Two example landing page now loads your "Authenticated" state, displaying your user's email and their Token.
After your first log in, click Log out. Then click Log in again. Notice how this time you will not be redirected to sign in as your state is already in the browser. Neat! If you clear the browser state for that tab, then you will have to be redirected away to sign-in again.

Learning more

Instant User Management, SSO, and Secure Pages for ReactJS with Keycloak

pnzrr — Wed, 02 Aug 2023 16:05:43 +0000

What is Keycloak?

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

INFO
If you just want to skip to the code, visit the Phase Two ReactJS example.

Setting up a Keycloak Instance

TIP
If you already have a functioning Keycloak instance, you can skip to the next section.

Details

Rather than trying to set up a "from scratch" instance of Keycloak, we're going to short-circuit that process by leveraging a Phase Two free Keycloak starter instance. The Starter provides a free hosted instance of Phase Two's enhanced Keycloak ready for light production use cases.

Visit the sign-up page.
Enter an email, use a Github account, or use an existing Google account to register.

Follow the register steps. This will include a sign-in link being sent to your email. Use that for password-less login.

After creating an account, a realm is automatically created for you with all of the Phase Two enhancements. You need to create a Deployment in the Shared Phase Two infrastructure in order to gain access to the realm. Without a deployment created, the Create Shared Deployment modal will automatically pop up.
Create a Shared Deployment by providing a region (pick something close to your existing infrastructure), a name for the deployment, and selecting the default organization that was created for you upon account creation. Hit "Confirm" when ready. Standby while our robots get to work generating your deployment. This can take a few seconds.

After the deployment is created and active, you can access the Keycloak Admin console by clicking "Open Console" for that deployment. Open it now to see the console.

At this point, move on to the next step in the tutorial. We'll be coming back to the Admin Console when its time to start connecting our App to the Keycloak instance.

Setting up an OIDC Client

We need to create a OpenID Connect Client in Keycloak for the app to communicate with.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Clients in the menu.
Click Create client.
Leave Client type set to OpenID Connect.
Enter a Client ID. This ID is an alphanumeric string that is used in OIDC requests and in the Keycloak database to identify the client.
Supply a Name for the client.
Click Next.
Under the Capability Config section, leave the defaults as selected. This can be configured further later.
Client authentication to Off.
Authorization to Off.
Standard flow checked. Direct access grants checked. All other items unchecked.
Click Next.
Under Login settings we need to add a redirect URI and Web origin in order. Assuming you are using the example application:
URI and Origin Details
The choice of localhost is arbitrary. If you are using an example application running locally, this will apply. If you are using an app that you actually have deployed somewhere, then you will need to substitute the appropriate URI for that.

Valid redirect URI (allows redirect back to application)
```
http://localhost:3000/*
```
Web origins (allows for Token auth call)
```
http://localhost:3000
```
Click Save

OIDC Config

Details

We will need values to configure our application. To get these values follow the instructions below.

Click Clients in the menu.
Find the Client you just created and click on it. In the top right click the Action dropdown and select Download adapter config.
Select Keycloak OIDC JSON in the format option. The details section will populate with the details we will need.
- Note the realm, auth-server-url, and resource values.

Adding a Non-Admin User

INFO
It is bad practice to use your Admin user to sign in to an Application.

Since we do not want to use our Admin user for signing into the app we will build, we need to add a another non-admin user.

Details

Open the Admin UI by clicking Open Console in the Phase Two Dashboard.
Click Users in the menu.
Click Add user.
Fill out the information for Email, First name, and Last name. Click Create.
We will now set the password for this user manually. Click Credentials (tab) and click Set Password. Provide a password for this user. For our use case, as a tutorial, you can leave "Temporary" set to "Off".
Click Save and confirm the password by clicking Save password

Setting up a ReactJS Project

INFO
We will use the Phase Two ReactJS example code here, but the logic could easily be applied to any existing application.

Clone the Phase Two example repo.
Open the ReactJS folder within /frameworks/reactjs.
Run npm install and then npm start. This example leverages react-oidc-context (which uses oidc-client-ts) to provide hook and HOC support.
Open the index.tsx file. We will be updating a few values from the prior section where we set up our OIDC client. Taking the values from the OIDC Client Config section, set those values in the code.

   const authServerUrl = "https://euc1.auth.ac/auth/";
   const realm = "shared-deployment-001";
   const client = "reg-example-1";

Those are used to popluate the OIDC config

   const oidcConfig = {
     authority: `${authServerUrl}realms/${realm}`,
     client_id: client,
     redirect_uri: "http://localhost:3000/authenticated",
     onSigninCallback: (args: any) =>
       window.history.replaceState(
         {},
         document.title,
         window.location.pathname
       ),
   };

The config is then provided to the AuthProvider.

   <AuthProvider {...oidcConfig}>
     <App />
   </AuthProvider>

At this point our entire applicationw will be able to access all information and methods needed to perform authentication. View Auth.tsx for exactly how the code is authenticating your user. The sections rendering the "Log in" and "Log out" buttons are conditional areas based on the authenticated context.

This login of using the hook to conditionally determine the Authenticated state, can be used to secure routes, components, and more.

Open localhost:3000. You will see the Phase Two example landing page. You current state should be "Not authenticated". Click Log In. This will redirect you to your login page.

INFO
Use the non-admin user created in the previous section to sign in.
Enter the credentials of the non-admin user you created. Click Submit. You will then be redirected to the application. The Phase Two example landing page now loads your "Authenticated" state, displaying your user's email and their Token.
After your first log in, click Log out. Then click Log in again. Notice how this time you will not be redirected to sign in as your state is already in the browser. Neat! If you clear the browser state for that tab, then you will have to be redirected away to sign-in again.

DEV Community: Phase Two

Securing Angular Apps with Keycloak

TOC

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Angular

Securing an Angular and Spring Boot Application with Keycloak

TOC

Setting up a Spring Boot project

Quick Start

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Install and configure Spring Boot

Testing the secured endpoints

Integration with Angular

Generate Angular Application

Securing views

User Authentication

Use Angular guards to secure routes

Learning more

Securing SvelteKit Apps with Keycloak

TOC

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Setting up a SvelteKit Project

Learning more

Securing Remix Apps with Keycloak

TOC

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Setting up a Remix Project

Learning more

User Management and Identity Brokering for On-Prem Apps with Keycloak

User Management and Identity Brokering for On-Prem Apps

A story, inspired by customer use cases:

An open source solution to the rescue

Tools to empower the customer

Keycloak: An open source alternative to Auth0, WorkOS, Okta, Cognito, ...

Commercial offerings

Open source alternatives

Barriers

Migrating from your current identity provider

Conclusion

Securing Vue Apps with Keycloak

TOC

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Setting up a Vue.js Project

Learning more

Securing Nuxt Apps with Keycloak

TOC

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Setting up a Nuxt Project

Using keycloak-js

Using oidc-client

Learning more

Django Web Authentication with Keycloak

TOC

Setting up a Django Project

Quick Start

Setting up a Keycloak Instance

Setting up an OIDC Client

OIDC Config

Adding a Non-Admin User

Install and configure the Django OIDC library

Using it in your app

Protect your views

Using `keycloak-js`

Using `oidc-client`