IDP

IDP

Keycloak

terminer le tls dans le traefik associé des attibut a un user: email, username realm: permet la separation entre user et client

keycloak client scope default don’t affect the old client since scope is stored inside the object client

the access token is like the keys that let the client to talk to the autorization server. Le header a l’access token et sont type e.g: bearer and expiration type

bellow mfurther the more secure, used the solution is.

but first there is 2 types of auth

• authentication who are you ?
• authrization what are you allowed to do ?

how ti works

A claim is a key–value pair inside a token (ID token or access token). Example of claims

{
  "sub": "12345",
  "email": "user@example.com",
  "preferred_username": "guillaume",
  "realm_access": {
    "roles": ["admin"]
  }
  "resource_access": {
    "client-name": {
      "roles": [...]
    }
  }
}

A mapper transforms internal data into token claims.

A scope controls what a client is allowed to access and which claims appear in tokens.

Scope → contient des mappers Client → attache des scopes

In JERNAS project we injected the roles claims at the root level since we can controle the apps. So in the client we mapped the groups to roles. And in each client created a mapper to get the roles oidc.client.client_id into the root claims.

Offline Token

Use case you app can be offline an the user modify info then logout, after reconnection the offline token allow the app to sync info even if the user if logout, no need of user interation.

Type of client

public can’t keep credentials secrets private can safely keep credentials secrets

Types of Auth

1. Basic Authentication

this auth isn’t secure unless used with enclave inside https (don’t use it) login request is

base64(username+password)

answer

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

2. htpasswd

like the basic but use bcrypt (hash)

username:passwor hash

5. Access VS refresh tokens

access token expires fast 15-60 min

the refresh allow to generete access token

refresh tokens days or weeks

the bearer token is just a type of access token.

7. OAuth2 + JWT (more later)

gold stendar for api auth

1. Refresh Token Flow

2. OpenID Connect (OIDC) Authorization Code Flow

for more infos https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85

6. SSO + identity protocols

Standar to exchang auth data between 2 parties

Service provider SP

salesforce school

IAM

AuthZ

define boundaries

roles

group

attributes

the models behind are give example for this…

• RBAC for ROLE BASE ACCESS CONTROl
• ABC attribute based access controle
• policy based

Identity Provider IdP

verifies your credentials issues a secure token if you’re legit hands that token off to app or sericeit make the authN made by: Google facebook

Step:

1. Auth the User password otp biometrics mfa

2. looks up the user’s identity LDAP Active Directory Okta Universal Directory

3. issues a secure token

Protocle

SAML

vs

WS federation

vs

???

but better and more used

vs

JWT

stateless not store on the server side improve calability store info about the user

example payload

{
  first header claim
  .
  data payloa
  first header claim
  .
  data payload
}d
}

also never store sentivie information inside jwt since it’s visible but anyone. this is a sign object but there is also opaque token

8.OIDC

this is an overlay on OAuth2 this is the gold standar for user auth and access (can be user also for api)

1. Authorization Code Flow (with PKCE)

2. Authorization Code Flow (with PKCE)

3. Client Credentials Flow (OIDC-adjacen)

for more infos https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660

access token

the access token

sequenceDiagram
    autonumber

    participant U as User (Browser)
    participant S as Service (Your App Backend)
    participant KC as Keycloak

    U->>S: Request protected resource
    S->>U: Redirect to Keycloak (Authorization Endpoint)

    U->>KC: GET /auth?<br/>client_id, scope=openid,<br/>state, code_challenge
    KC->>U: Login page
    U->>KC: Submit credentials (POST)

    KC->>U: Redirect to Service with<br/>?code & state

    U->>S: GET /callback?code=...
    S->>KC: POST /token<br/>code, redirect_uri,<br/>client_id, code_verifier
    KC->>S: id_token + access_token

    S->>S: Validate tokens<br/>Create session
    S->>U: Set session cookie

    U->>S: Request protected resource<br/>(with cookie)
    S->>U: Protected response

Types of oAuth flow

1. Authrization code flow

use when the application need to access protected resources on behalf of the users.

2. client credentials flow when the app does not access protect resouces on the behalf of the user, but this own protected resources.

3. Resource owner password flow

4. implicit flow

Types of OIDC

PKCE (Pixie)

it’s a extension for code grant very usefull when you are or SPA don’t have database so can’t store the secrets of keycloak like the use in:

• mobile apps
• single page applications

like a dynaimique handshak it makes a one time verification request.

this allow protection agsent authorisation code interception.

because in a app if you decompli it you can get the code

fetch('https://something.com/token', {
  method: 'POST',
  body: new URLSearchParam({
    grant_type: 'autorization_code',
    code: 'codeee there',
    client_id: 'my_service',
  }),
});

flowchart LR
    %% Client Side
    subgraph Client["Client App"]
        D[Send Code Verifier\nToken Exchange]
        C[Send Code Challenge\nAuth Request]
        B[Derive Code Challenge\nSHA-256 + Base64URL]
        A[Generate Code Verifier]
        A --> B --> C
    end

    %% Authorization Server Side
    subgraph AS["Authorization Server"]
        E[Receive Code Challenge]
        F[Store Code Challenge]
        G[Receive Code Verifier]
        H[Verify Challenge\nhashverifier == challenge]
        I[Issue Tokens]
        E --> F
        G -- compare verifier to stored challenge --> H --if match issue tokens--> I
    end

    %% Cross-system interactions
    C -->|during auth request| E
    D -->|during token exchange| G

    %% Styles
    classDef client fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#e0f2fe;
    classDef server fill:#052e16,stroke:#22c55e,stroke-width:2px,color:#dcfce7;
    classDef highlight fill:#312e81,stroke:#a5b4fc,stroke-width:2px,color:#e0e7ff;

    %% Apply classes
    class A,B,C,D client;
    class E,F,G,H,I server;
    class H,I highlight;

    %% Subgraph styling
    style Client fill:#020617,stroke:#38bdf8,stroke-width:2px,color:#e0f2fe
    style AS fill:#022c22,stroke:#22c55e,stroke-width:2px,color:#dcfce7

In short PKCE is the gold standar it’s recommanded even for confidential clients and mandatory for public client.

What to use ?

Client type	Recommended today
SPA (browser)	Auth Code + PKCE
Mobile apps	Auth Code + PKCE
Desktop apps	Auth Code + PKCE
Backend web apps	Auth Code + PKCE (+ client_secret)
Machine-to-machine	Client Credentials
Legacy only	Implicit (deprecated ❌)

No longer secure

Grant type	Status
Implicit Grant	❌ Deprecated
Password Grant	❌ Deprecated
Auth Code without PKCE	❌ Discouraged
Hybrid flows	⚠️ Rare / niche

SCIM

scim allow configuration on all app / service how to create and manage the user. once the user is updated inside all the apps with SCIM so is a specification on how to build rest api for managing user or group so Azure can delete a user.

DEX

keycloak vs dex ?

If you already have existing Identity Provider (AD, SAML, Github..etc) and just need an OIDC interface to bridge applications with a centralized service. Dex is your choice.

If you need custom claim from OIDC provider and also looking for replace existing Identity provider. And you expect more programatic automation with Identity provider. Keycloak definitely can fulfill the requirement and with REST API support.