DEV Community: DKForge

How SSH Actually Works (Step-by-Step for Developers)

DKForge — Sat, 04 Apr 2026 08:49:13 +0000

Most developers use SSH every day:

ssh user@server

…but very few know what’s actually happening under the hood.

Let’s break it down 👇

🚀 1. TCP Connection

Everything starts with a basic TCP connection between client and server.

At this stage:

No encryption yet
Just a raw connection

🤝 2. Negotiation Phase

The client and server exchange:

SSH protocol versions
Supported encryption algorithms
Key exchange methods

They agree on a secure configuration before continuing.

🔑 3. Session Key Generation

SSH uses a key exchange algorithm (e.g. Diffie-Hellman) to generate a shared session key.

Client -------- Key Exchange -------- Server
         -> shared secret key <-

👉 This session key is used for encrypting all communication.

🔐 4. Authentication (Public Key)

If you're using SSH keys:

Generate SSH key

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Copy public key to server

ssh-copy-id user@server

Or manually:

cat ~/.ssh/id_rsa.pub

Paste into:

~/.ssh/authorized_keys

👉 The server checks if your public key exists there.

✅ 5. Verification

The server sends an encrypted challenge.

The client decrypts it using its private key.

👉 If successful → authentication is complete.

🔄 6. Encrypted Communication

Now everything is encrypted using the session key:

Commands
Responses
Data

Example:

ls -la

👉 Sent encrypted → executed → returned encrypted

⚡ 7. Command Execution Flow

Client -> (encrypted command) -> Server
Server -> (execute command)
Server -> (encrypted response) -> Client
Client -> (decrypt response)

🌐 Bonus: SSH Tunneling (Port Forwarding)

SSH can create secure tunnels.

Example:

ssh -L 3000:localhost:5432 user@remote-server

👉 Now you can connect to the remote DB via:

localhost:3000

🧠 Why SSH Is So Powerful

Uses asymmetric cryptography (public/private keys)
Establishes a fast symmetric session key
Protects against eavesdropping and MITM attacks

🔐 Best Practices

# Disable password authentication (server-side)
PasswordAuthentication no

# Set correct permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Use SSH agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

💭 Question

Do you use password authentication or SSH keys in your setup?

Things I Learned While Building Custom Keycloak Themes

DKForge — Sat, 14 Mar 2026 17:50:20 +0000

Keycloak’s theme system looks simple at first, but once you start building custom login experiences you quickly discover a few non-obvious things.

Customizing authentication UIs is often necessary when integrating Keycloak into a product where branding and user experience matter.

After experimenting with several custom Keycloak themes, here are a few practical things I learned while customizing the authentication UI.

1. Most UI customization happens in just a few files

At first I expected Keycloak theming to require modifying many templates, but in practice most UI changes happen in just a few places.

login/
  template.ftl
  login.ftl
  theme.properties
  resources/css/*

The template.ftl file is particularly important because it defines the layout used across multiple pages.

Once you customize that file, changes automatically apply to:

login
register
reset password
verification flows

This makes it easier to build a consistent authentication UI.

2. CSS overrides are usually safer than modifying templates

A common temptation when customizing Keycloak is editing the FreeMarker templates directly.

However, in many cases you can achieve the same result by simply overriding CSS classes.

For example:

.kc-button {
  background: linear-gradient(135deg,#00d9ff,#0099cc);
  border-radius:6px;
  padding:14px 32px;
}

This approach keeps templates cleaner and makes theme maintenance easier when upgrading Keycloak.

3. Email templates behave very differently from login pages

One thing that surprised me while working on themes was how different email templates are compared to login pages.

Modern CSS features often don’t work consistently in email clients.

For example, gradients may require fallback colors:

background:#00d9ff;
background:linear-gradient(135deg,#00d9ff,#0099cc);

Many email clients also ignore transitions or hover effects, so email templates should be designed with progressive enhancement in mind.

4. Previewing themes locally saves a lot of time

Testing authentication flows manually can be slow.

Using a local Keycloak instance (for example with Docker) makes it much easier to test:

login flows
password reset
email verification
OTP flows

Being able to quickly restart Keycloak and reload the theme speeds up development significantly.

Example: Custom Login UI

While experimenting with Keycloak themes, I wanted to see how far the default login experience could be customized.

Below is a comparison between the default Keycloak login page and two custom themes built using the theme system.

Default Keycloak login

Custom Login theme – FutureMax style

Custom Login Theme - Business style

Even though the visual design changes completely, the underlying authentication flow remains exactly the same.
The theme system only affects the presentation layer while Keycloak continues to handle authentication, sessions and security.

For reference, I published the Business theme here as an example:

GitHub repository:
DKForge Business Theme For Keycloak

The repository shows a basic Keycloak theme structure and how the login UI can be customized through FreeMarker templates and CSS.

Summary

Keycloak’s theme system allows developers to completely customize the authentication interface without changing the underlying authentication logic.

By modifying FreeMarker templates and overriding styles, it’s possible to transform the default login UI into a fully branded experience that fits the product.

Even small UI changes can significantly improve the overall authentication experience while still relying on Keycloak’s secure authentication flows.

Enabling HTTPS on an Application Server using Keytool

DKForge — Sat, 14 Mar 2026 08:32:28 +0000

Overview

This guide explains how to configure HTTPS (SSL/TLS) for an application server using a certificate issued by a Certificate Authority (CA) and the Java keytool utility.

The process includes:

1) Creating a keystore and generating a private key
2) Generating a Certificate Signing Request (CSR)
3) Importing signed certificates from the Certificate Authority
4) Configuring the application server to use the keystore
5) Testing the HTTPS connection

⚠️ The exact configuration of the application server may vary depending on the server software being used.
Always verify SSL configuration compatibility with your specific application server.

1. Create a Keystore and Private Key

Use the Java keytool utility to create a keystore and generate a key pair.

keytool -genkeypair -alias <key_alias> -keyalg RSA -keysize 2048 -keystore <keystore_file> -validity 365

Paramaters explanation

Parameter	Description
`-genkeypair`	Creates a new key pair (private key + self-signed certificate).
`-alias <key_alias>`	Unique name identifying the key inside the keystore. This alias will later be used by the application server to locate the private key.
`-keyalg RSA`	Specifies the encryption algorithm used for the key pair. RSA is commonly used for SSL certificates.
`-keysize 2048`	Defines the key size in bits. 2048 is a common secure size.
`-keystore <keystore_file>`	The name of the keystore file that will be created. The keystore stores private keys and certificates.
`-validity 365`	Defines how long the generated certificate will remain valid (in days).

During execution, the command will prompt you for:

Keystore password
Organization details
Common Name (CN)

The Common Name (CN) must match the fully qualified domain name (FQDN) of the server.

Example:

api.example.com

2. Generate a Certificate Signing Request (CSR)

The CSR is sent to the Certificate Authority to issue a trusted certificate.

keytool -certreq -alias <key_alias> -file <csr_file> -keystore <keystore_file>

Parameters explanation

Parameter	Description
`-certreq`	Generates a certificate signing request.
`-alias <key_alias>`	The alias of the private key that the CSR will be generated for.
`-file <csr_file>`	Output CSR file.
`-keystore <keystore_file>`	The keystore containing the private key.

The resulting file should be sent to the Certificate Authority (CA).

The CA typically returns:

Server certificate
Intermediate certificate(s)
Root certificate

3. Import Certificates into the Keystore

Certificates must be imported in the correct order to form a valid certificate chain.

3.1 Import the Root Certificate

keytool -import -alias <root_alias> -file <root_certificate> -keystore <keystore_file>

Parameters

Parameter	Description
`<root_alias>`	Alias name for the root certificate entry.
`<root_certificate>`	Root certificate file provided by the CA.
`<keystore_file>`	The keystore where the certificate will be stored.

3.2 Import the Intermediate Certificate

keytool -import -alias <intermediate_alias> -file <intermediate_certificate> -keystore <keystore_file>

Parameters

Parameter	Description
`<intermediate_alias>`	Alias name for the intermediate CA certificate.
`<intermediate_certificate>`	Intermediate certificate file provided by the CA.
`<keystore_file>`	Target keystore.

3.3 Import the Server Certificate

The server certificate must be imported using the same alias as the private key.

keytool -import -alias <key_alias> -file <server_certificate> -keystore <keystore_file>

Parameters

Parameter	Description
`<key_alias>`	Alias of the private key created in Step 1.
`<server_certificate>`	Signed certificate returned by the Certificate Authority.
`<keystore_file>`	Target keystore.

4. Verify the Certificate Chain

After importing the certificates, verify that the certificate chain was created correctly.

keytool -list -v -alias <key_alias> -keystore <keystore_file>

Parameters

Parameter	Description
`-list`	Lists the entries stored in the keystore.
`-v`	Displays detailed certificate information.
`<key_alias>`	Alias of the private key entry.
`<keystore_file>`	Target keystore.

Expected result:

Entry type: PrivateKeyEntry
Certificate chain length: 3

Typical certificate chain order:

Certificate[1] → Server Certificate
Certificate[2] → Intermediate CA
Certificate[3] → Root CA

5.Configure the Application Server

The keystore must be referenced in the server's SSL configuration.

Example generic configuration parameters:

SSL Enabled: true
HTTPS Port: 8443
Keystore File: <path_to_keystore>
Keystore Password: <keystore_password>
Key Alias: <key_alias>
SSL Protocol: TLS

⚠️ The exact configuration syntax depends on the application server.
Consult the server documentation to verify the correct SSL configuration method.

Example: HTTPS Configuration using a Java Keystore (Tomcat server.xml)

The following example demonstrates how an HTTPS connector may be configured in a server that uses a Java keystore.

⚠️ This is only an example configuration.
Different application servers use different configuration formats.

<!-- Example HTTP connector -->
<Connector port="8080"
           protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

<!-- Example HTTPS connector -->
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443"
           maxThreads="200"
           scheme="https"
           secure="true"
           SSLEnabled="true"
           keystoreFile="<path_to_keystore>"
           keystorePass="<keystore_password>"
           keyAlias="<key_alias>"
           clientAuth="false"
           sslProtocol="TLS"/>

<!-- Optional AJP connector -->
<Connector port="8009"
           protocol="AJP/1.3"
           redirectPort="8443"/>

Explanation of Configuration Parameters

Parameter	Description
`port`	Port used by the HTTPS connector (commonly 8443).
`protocol`	HTTP protocol implementation used by the server.
`SSLEnabled`	Enables SSL/TLS encryption.
`scheme="https"`	Indicates that the connector handles HTTPS traffic.
`secure="true"`	Marks the connection as secure.
`keystoreFile`	Path to the Java keystore containing the server certificate and private key.
`keystorePass`	Password used to access the keystore.
`keyAlias`	Alias of the private key stored in the keystore.
`sslProtocol`	Defines the TLS protocol used for encrypted communication.
`clientAuth`	Indicates whether client certificate authentication is required.

Placholder Example:

<path_to_keystore>  → /opt/app/security/server_keystore.jks
<keystore_password> → changeit
<key_alias>         → server-cert

6.Restart the Application Server

Restart the server to apply the new HTTPS configuration.

Check the server logs for SSL initialization messages.

Typical log example:

Initializing HTTPS connector
Starting SSL listener

7.Test HTTPS Connectivity

Test using curl

curl -vk https://<server_hostname>:<port>

Parameters

Parameter	Description
`-v`	Enables verbose output.
`-k`	Allows insecure SSL connections (useful for testing).
`<server_hostname>`	Hostname or FQDN of the server.
`<port>`	HTTPS port configured on the server.

Troubleshooting

Different keystore format

Occurs when the server expects a different keystore format.

Possible causes:

PKCS12 keystore used where JKS is expected
Corrupted keystore file

Verify keystore type:

keytool -list -keystore <keystore_file>

Certificate chain length = 1

This means the server certificate was imported without the CA certificates.

Solution:

Import certificates in this order:

1) Root CA

2) Intermediate CA

3) Server certificate

Alias mismatch

If the server cannot locate the private key, the alias configured in the server must match the alias used during keystore creation.

Example:

Key Alias: <key_alias>

Summary

HTTPS configuration generally includes the following steps:

Create a keystore and private key
Generate a CSR
Obtain certificates from a Certificate Authority
Import certificates into the keystore
Verify the certificate chain
Configure the application server to use the keystore
Restart the server
Test the HTTPS endpoint

OAuth2 vs OpenID Connect: What's the Difference?

DKForge — Sat, 07 Mar 2026 16:22:12 +0000

OAuth2 and OpenID Connect are often mentioned together, and many developers assume they solve the same problem.

In reality, they serve different purposes.

Understanding the difference is essential when designing authentication and authorization systems.

What OAuth2 Actually Is

OAuth2 is an authorization framework.

It allows an application to access resources on behalf of a user without sharing the user's credentials.

Instead of sending a username and password to every service, the client receives an access token issued by an Authorization Server.

That token can then be used to request resources from a Resource Server.

Example scenario:

A user allows a third-party application to access their data stored in another service.

OAuth2 enables this delegation securely.

Why OAuth2 Is Not Authentication

A common misconception is that OAuth2 is used for authentication.

OAuth2 does not tell an application who the user is.

It only answers the question:

Is this client allowed to access this resource?

An access token proves that the client has permission, but it does not provide reliable identity information about the user.

Because of this limitation, OAuth2 alone is not sufficient for authentication.

What OpenID Connect Adds

OpenID Connect (OIDC) is a layer built on top of OAuth2.

It adds the missing piece: authentication.

OIDC introduces a new token type called the ID Token.

The ID Token contains identity information about the authenticated user, such as:

User identifier
Issuer
Authentication time
Token expiration

This allows the client application to confirm who the user is.

In other words:

Technology	Purpose
OAuth2	Authorization
OpenID Connect	Authentication

ID Token vs Access Token

Understanding the difference between these two tokens is important.

Access Token

Used to access protected resources.

Example:

GET /api/user-data
Authorization: Bearer access_token

The resource server validates the token and returns the requested data.

ID Token

Used to identify the authenticated user.

The client application can inspect the token to obtain identity information.

Typical fields in an ID Token include:

sub (user identifier)
iss (issuer)
aud (audience)
exp (expiration time)

ID Tokens are commonly implemented as JWT tokens.

Real Example Flow

A simplified OpenID Connect flow looks like this:

The user attempts to log in to an application.
The application redirects the user to an Authorization Server.
The user authenticates (login, MFA, etc.).
The Authorization Server issues:
- an Access Token
- an ID Token
The application uses the ID Token to identify the user.
The Access Token is used to request data from APIs.

Conclusion

OAuth2 and OpenID Connect work together but serve different roles.

OAuth2 provides authorization.

OpenID Connect provides authentication by adding identity information on top of OAuth2.

Understanding this distinction helps developers design secure and scalable authentication systems.

If you want to understand the different OAuth2 flows in detail, you can read my previous article:

Understanding OAuth2 Grant Types

https://dev.to/dkforge/understanding-oauth2-grant-types-50p8

Understanding OAuth2 Grant Types

DKForge — Sat, 07 Mar 2026 01:12:35 +0000

OAuth2 is one of the most widely used authorization frameworks in modern applications.

However, many developers struggle to understand when to use each grant type and how the flows actually work.

In this guide we break down the most common OAuth2 grant types with diagrams and practical explanations.

Overview of OAuth2
What is a Grant Type?
Grant Types
- Authorization Code Grant
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
- Refresh Token Grant
- Device Authorization Grant
Conclusion

Overview of OAuth2

OAuth2 is designed to provide a secure way for applications to obtain access to user data without requiring the user to share their credentials. Instead, it uses access tokens issued by an Authorization Server to allow applications to request data from a Resource Server.

What is a Grant Type?

A grant type in OAuth2 is a method by which a client application obtains an access token. It defines the flow that an application follows to request and receive authorization from an authorization server. Different grant types exist to accommodate various security needs and application types.

Grant Types

Authorization Code Grant

sequenceDiagram
  actor User
  participant Browser
  participant App Server
  participant Authorization Server
  participant Resource Server

  User ->> Browser: 
  Browser ->> App Server: GET/index.html
  App Server -->> Authorization Server: Redirect to Authorization Server
  Authorization Server ->> Browser: Display Login Page
  Browser ->> Authorization Server: Enters Credentials(username,password)
  Authorization Server ->> Authorization Server: User Authentication
  Authorization Server -->> App Server: Redirect back to app wihth grant code(auth code)
  App Server ->> Authorization Server: get tokens by sending the grant code(auth code)
  Authorization Server ->> App Server: return access token
  App Server ->> Resource Server: get data sending the token
  Resource Server->>App Server:return data
  App Server->>Browser:display data/index.html

The Authorization Code Grant is used by web applications and follows a redirection-based flow to obtain an access token securely.

Steps:

The user accesses a web application and is redirected to an Authorization Server for authentication.
The user logs in, and if successful, the Authorization Server redirects back to the application with an authorization code.
The application exchanges this authorization code for an access token.
The access token is then used to request protected resources from the Resource Server.

Implicit Grant

sequenceDiagram
  actor User
  participant Browser
  participant App Server
  participant Authorization Server
  participant Resource Server

  User ->> Browser: 
  Browser ->> App Server: GET/index.html
  App Server -->> Authorization Server: Redirect or popup to Authorization Server
  Authorization Server ->> Browser: Display Login Page
  Browser ->> Authorization Server: Enters Credentials(username,password)
  Authorization Server ->> Authorization Server: User Authentication/Credentials validated
  Authorization Server -->> App Server: Redirect back to app with access token in the URL
  App Server-->>Browser:Token
  Browser ->> Resource Server: get data sending the token
  Resource Server->>Browser:return data

The Implicit Grant is used for single-page applications (SPAs) where storing client secrets securely is not possible. It directly provides an access token.

Steps

The user is redirected to the Authorization Server, logs in, and approves access.
Instead of returning an authorization code, the Authorization Server directly returns an access token in the URL.
The client application uses this token to access the Resource Server.

⚠️ Note: The Implicit Grant is now considered deprecated in OAuth 2.1 and modern applications should use the Authorization Code flow with PKCE instead.

Resource Owner Password Credentials Grant

sequenceDiagram
  actor User
  participant Browser
  participant App Server
  participant Authorization Server
  participant Resource Server

  User ->> Browser: 
  Browser ->> App Server: GET/index.html
  App Server ->> Browser: Display Login page
  Browser ->> App Server: User Credentials
  App Server ->> Authorization Server: Get tokens sending User Credentials
  Authorization Server ->> App Server: Access Token
  App Server ->> Resource Server: Get data sending the token
  Resource Server->>App Server:Return data
  App Server->>Browser: index.html

Used when the application is trusted, and the user directly provides their credentials to the client application.

Steps

The user enters their credentials directly into the application.
The application sends these credentials to the Authorization Server.
If valid, the Authorization Server responds with an access token.
The application uses the access token to request data from the Resource Server.

Client Credentials Grant

sequenceDiagram
  participant App Server
  participant Authorization Server
  participant Resource Server

  App Server ->> Authorization Server: Get tokens sending Client Credentials(client_id,client secret)
  Authorization Server ->> App Server: Access Token
  App Server ->> Resource Server: Get data sending the token
  Resource Server->>App Server:Return data

Used when a client application needs to access its own resources without user intervention.

Explanation

The application sends its client ID and secret to the Authorization Server.
If valid, the Authorization Server responds with an access token.
The application uses the token to access the Resource Server.

Refresh Token Grant

sequenceDiagram
    actor User
    participant ClientApplication
    participant AuthorizationServer
    participant ResourceServer

    User->>ClientApplication: Initiates login
    ClientApplication->>AuthorizationServer: Redirects to authorization endpoint
    AuthorizationServer->>User: Prompts for authentication
    User->>AuthorizationServer: Provides credentials
    AuthorizationServer-->>ClientApplication: Returns authorization code
    ClientApplication->>AuthorizationServer: Exchanges authorization code for tokens (access token + refresh token)
    AuthorizationServer-->>ClientApplication: Returns access token and refresh token

    ClientApplication->>ResourceServer: Uses access token to access resources
    ResourceServer-->>ClientApplication: Returns requested resources

    Note over ClientApplication,AuthorizationServer: Access token expires
    ClientApplication->>AuthorizationServer: Requests new access token using refresh token
    AuthorizationServer-->>ClientApplication: Returns new access token (and optionally a new refresh token)

    ClientApplication->>ResourceServer: Uses new access token to access resources
    ResourceServer-->>ClientApplication: Returns requested resources

Allows clients to obtain a new access token using a refresh token without requiring user intervention.

Steps

The client application initially receives both an access token and a refresh token after a successful authentication process using a grant type(e.g. Authorization Code grant).
The client uses the access token to request protected resources.
When the access token expires, the client sends the refresh token to the Authorization Server.
If the refresh token is valid, the Authorization Server returns a new access token (and optionally a new refresh token).
The client continues using the new access token to access resources.

Device Authorization Grant

sequenceDiagram
    actor User 
    participant Device
    participant AuthorizationServer
    participant ClientApplication

    User->>Device: Initiates device authorization
    Device->>AuthorizationServer: Request device authorization
    AuthorizationServer-->>Device: Returns device code and user code
    Device-->>User: Displays user code and verification URI

    User->>AuthorizationServer: Navigates to verification URI and enters user code
    AuthorizationServer->>User: Prompts user to authorize the device
    User->>AuthorizationServer: Authorizes the device

    AuthorizationServer->>Device: Polling for authorization status
    Device->>AuthorizationServer: Polling request with device code
    AuthorizationServer-->>Device: Returns access token (if authorized)

    Device->>ClientApplication: Uses access token to access resources
    ClientApplication-->>Device: Returns requested resources

Used for devices with limited input capabilities, such as smart TVs and IoT devices.

Steps:

The user initiates the device authorization.
The device requests authorization from the Authorization Server.
The Authorization Server returns a device code and a user code.
The device displays the user code and verification URI.
The user navigates to the verification URI and enters the user code.
The Authorization Server prompts the user to authorize the device.
Once approved, the device polls the Authorization Server for the access token.
The Authorization Server issues an access token.

Conclusion

OAuth2 provides multiple grant types to support different application architectures.

Choosing the correct flow depends on:

Security requirements
Client type (web, mobile, server-to-server)
User interaction needs

In modern architectures the most commonly used flows are:

Authorization Code + PKCE
Client Credentials
Refresh Token

Understanding these flows helps developers design secure authentication and authorization systems.

DEV Community: DKForge

How SSH Actually Works (Step-by-Step for Developers)

🚀 1. TCP Connection

🤝 2. Negotiation Phase

🔑 3. Session Key Generation

🔐 4. Authentication (Public Key)

Generate SSH key

Copy public key to server

Or manually:

✅ 5. Verification

🔄 6. Encrypted Communication

⚡ 7. Command Execution Flow

🌐 Bonus: SSH Tunneling (Port Forwarding)

Example:

🧠 Why SSH Is So Powerful

🔐 Best Practices

💭 Question

Things I Learned While Building Custom Keycloak Themes

1. Most UI customization happens in just a few files

2. CSS overrides are usually safer than modifying templates

3. Email templates behave very differently from login pages

4. Previewing themes locally saves a lot of time

Example: Custom Login UI

Summary

Enabling HTTPS on an Application Server using Keytool

Overview

1. Create a Keystore and Private Key

Paramaters explanation

2. Generate a Certificate Signing Request (CSR)

Parameters explanation

3. Import Certificates into the Keystore

3.1 Import the Root Certificate

Parameters

3.2 Import the Intermediate Certificate

Parameters

3.3 Import the Server Certificate

Parameters

4. Verify the Certificate Chain

Parameters

5.Configure the Application Server

Example: HTTPS Configuration using a Java Keystore (Tomcat server.xml)

Explanation of Configuration Parameters

6.Restart the Application Server

7.Test HTTPS Connectivity

Test using curl

Parameters

Troubleshooting

Different keystore format

Certificate chain length = 1

Alias mismatch

Summary

OAuth2 vs OpenID Connect: What's the Difference?

What OAuth2 Actually Is

Why OAuth2 Is Not Authentication

What OpenID Connect Adds

ID Token vs Access Token

Access Token

ID Token

Real Example Flow

Conclusion

Understanding OAuth2 Grant Types

Table of Contents

Overview of OAuth2

What is a Grant Type?

Grant Types

Authorization Code Grant

Steps:

Implicit Grant

Steps

Resource Owner Password Credentials Grant

Steps

Client Credentials Grant

Explanation

Refresh Token Grant

Steps

Device Authorization Grant

Steps:

Conclusion