SSO Redirect Post Enrollment Error #445

Closed
opened 2026-02-04 19:34:00 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @tomlyo on GitHub (Mar 22, 2024).

I'm finding an issue when new users sign up for an account on Planka via my IDP. Steps to recreate the issue are below:

  1. Go my my Planka site, click "Login with SSO" (OIDC_ENFORCED is true).
  2. Redirected to my IDP (Authentik). They sign up for a new account, and verify their email and log back in.
  3. Authentik redirects back to the application with this URL: https://planka.<>.com/oidc-callback#code=<>&state=<>
  4. They land on the Planka webpage, Unknown error, try again later. Nothing is logged by Planka regarding this.)
  5. Check PostgreSQL, no user exists in the user_account table.
  6. User clicks "Login with SSO" again, and log in to the application successfully. User is now in the planka database.

Planka V1.16.0
Authentik V2024.2.2
planka

Docker-Compose:

version: '3'

services:
  planka:
    container_name: planka
    image: ghcr.io/plankanban/planka:1.16.0
    restart: on-failure
    volumes:
      - ${VOLUME}/user-avatars:/app/public/user-avatars
      - ${VOLUME}/project-background-images:/app/public/project-background-images
      - ${VOLUME}/attachments:/app/private/attachments
    ports:
      - 3246:1337
    environment:
      - BASE_URL=${BASE_URL}
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=${SECRET_KEY}
      - TRUST_PROXY=1
      - OIDC_ISSUER=${OIDC_ISSUER}
      - OIDC_CLIENT_ID=${OIDC_CLIENT_ID}
      - OIDC_CLIENT_SECRET=${OIDC_CLIENT_SECRET}
      - OIDC_SCOPES=openid email profile
      - OIDC_USERNAME_ATTRIBUTE=preferred_username
      - OIDC_IGNORE_ROLES=false
      - OIDC_ADMIN_ROLES=planka-admins
      - OIDC_EMAIL_ATTRIBUTE=email
      - OIDC_NAME_ATTRIBUTE=preferred_username
      - OIDC_ENFORCED=true
      - SMTP_HOST=${SMTP_HOST}
      - SMTP_USER=${SMTP_USER}
      - SMTP_PASSWORD=${SMTP_PASSWORD}
      - SMTP_PORT=${SMTP_PORT}
      - SMTP_FROM=${SMTP_FROM}
      - SMTP_SECURE=false
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    container_name: planka-db
    image: postgres:14-alpine
    restart: on-failure
    volumes:
      - ${VOLUME}/db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5
Originally created by @tomlyo on GitHub (Mar 22, 2024). I'm finding an issue when new users sign up for an account on Planka via my IDP. Steps to recreate the issue are below: 1. Go my my Planka site, click "Login with SSO" (OIDC_ENFORCED is true). 2. Redirected to my IDP (Authentik). They sign up for a new account, and verify their email and log back in. 3. Authentik redirects back to the application with this URL: https://planka.<>.com/oidc-callback#code=<>&state=<> 4. They land on the Planka webpage, Unknown error, try again later. Nothing is logged by Planka regarding this.) 5. Check PostgreSQL, no user exists in the user_account table. 6. User clicks "Login with SSO" again, and log in to the application successfully. User is now in the planka database. Planka V1.16.0 Authentik V2024.2.2 ![planka](https://github.com/plankanban/planka/assets/90040568/28f07bc0-fa5c-48fb-8c00-ab041e4c60d1) Docker-Compose: ``` version: '3' services: planka: container_name: planka image: ghcr.io/plankanban/planka:1.16.0 restart: on-failure volumes: - ${VOLUME}/user-avatars:/app/public/user-avatars - ${VOLUME}/project-background-images:/app/public/project-background-images - ${VOLUME}/attachments:/app/private/attachments ports: - 3246:1337 environment: - BASE_URL=${BASE_URL} - DATABASE_URL=postgresql://postgres@postgres/planka - SECRET_KEY=${SECRET_KEY} - TRUST_PROXY=1 - OIDC_ISSUER=${OIDC_ISSUER} - OIDC_CLIENT_ID=${OIDC_CLIENT_ID} - OIDC_CLIENT_SECRET=${OIDC_CLIENT_SECRET} - OIDC_SCOPES=openid email profile - OIDC_USERNAME_ATTRIBUTE=preferred_username - OIDC_IGNORE_ROLES=false - OIDC_ADMIN_ROLES=planka-admins - OIDC_EMAIL_ATTRIBUTE=email - OIDC_NAME_ATTRIBUTE=preferred_username - OIDC_ENFORCED=true - SMTP_HOST=${SMTP_HOST} - SMTP_USER=${SMTP_USER} - SMTP_PASSWORD=${SMTP_PASSWORD} - SMTP_PORT=${SMTP_PORT} - SMTP_FROM=${SMTP_FROM} - SMTP_SECURE=false depends_on: postgres: condition: service_healthy postgres: container_name: planka-db image: postgres:14-alpine restart: on-failure volumes: - ${VOLUME}/db-data:/var/lib/postgresql/data environment: - POSTGRES_DB=planka - POSTGRES_HOST_AUTH_METHOD=trust healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d planka"] interval: 10s timeout: 5s retries: 5 ```
OVERLORD added the bug label 2026-02-04 19:34:00 +03:00
Author
Owner

@meltyshev commented on GitHub (Mar 25, 2024):

Hi and thanks for reporting this!
As far as I understand, it doesn't happen every time when logging in as a new user? I've tried to reproduce this several times, but have never had this problem.
But we definitely need to add more detailed error output.

@meltyshev commented on GitHub (Mar 25, 2024): Hi and thanks for reporting this! As far as I understand, it doesn't happen every time when logging in as a new user? I've tried to reproduce this several times, but have never had this problem. But we definitely need to add more detailed error output.
Author
Owner

@tomlyo commented on GitHub (Mar 26, 2024):

Hi,

That is correct, it only happens immediately after a user enrolls, and is redirected back to planka. I've tried inspecting the headers and request data when the user clicks the link in the email to Authentik then back to Planka, versus just clicking the "Sign in with SSO", and they appear to be the same.

No better way of showcasing an issue than a video though (45 seconds showcasing the error):

https://github.com/plankanban/planka/assets/90040568/15013e0d-46e6-4d6a-b4bf-34fcc97109ab

Note: This is a test environment that was set up specifically for this purpose. The issue was originally present in a # "production environment".

@tomlyo commented on GitHub (Mar 26, 2024): Hi, That is correct, it only happens immediately after a user enrolls, and is redirected back to planka. I've tried inspecting the headers and request data when the user clicks the link in the email to Authentik then back to Planka, versus just clicking the "Sign in with SSO", and they appear to be the same. No better way of showcasing an issue than a video though (45 seconds showcasing the error): https://github.com/plankanban/planka/assets/90040568/15013e0d-46e6-4d6a-b4bf-34fcc97109ab Note: This is a test environment that was set up specifically for this purpose. The issue was originally present in a # "production environment".
Author
Owner

@meltyshev commented on GitHub (Mar 26, 2024):

Thanks for the video!

Now I see what the problem is. Before redirecting from Planka to Authentik we create an oidc-state variable and store it in the sessionStorage, it's needed for better security, so that we can verify that it was you who pressed the "Log in With SSO" button. But when you follow a link from the email, another tab opens where oidc-state is missing (since sessionStorage only works for the current session). Then when redirecting back to Planka, we check if oidc-state matches and since it's not present at all, we immediately output an error and don't even send any requests to the server.

When testing I missed the step that you received the link in an email, my bad. I'll try a quick fix for this, but first I need to research a bit if there's anything wrong in terms of security if storing oidc-state to more than just the current tab.

@meltyshev commented on GitHub (Mar 26, 2024): Thanks for the video! Now I see what the problem is. Before redirecting from Planka to Authentik we create an `oidc-state` variable and store it in the `sessionStorage`, it's needed for better security, so that we can verify that it was you who pressed the "Log in With SSO" button. But when you follow a link from the email, another tab opens where `oidc-state` is missing (since `sessionStorage` only works for the current session). Then when redirecting back to Planka, we check if `oidc-state` matches and since it's not present at all, we immediately output an error and don't even send any requests to the server. When testing I missed the step that you received the link in an email, my bad. I'll try a quick fix for this, but first I need to research a bit if there's anything wrong in terms of security if storing `oidc-state` to more than just the current tab.
Author
Owner

@meltyshev commented on GitHub (Mar 26, 2024):

It seems that there should be no security issues if we replace sessionStorage with localStorage and in that case it will work correctly. Checked the description of the state parameter in the documentation, the oidc-client-ts library uses localStorage and the same in the example here: https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/mitigate-replay-attacks-when-using-the-implicit-flow#persist-nonces-across-requests.

@meltyshev commented on GitHub (Mar 26, 2024): It seems that there should be no security issues if we replace `sessionStorage` with `localStorage` and in that case it will work correctly. Checked the description of the `state` parameter in the documentation, the oidc-client-ts library uses `localStorage` and the same in the example here: https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/mitigate-replay-attacks-when-using-the-implicit-flow#persist-nonces-across-requests.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/planka#445