OIDC tinyauth

[UntriexTv]

The bug

When logging in through tinyauth, where I have LLDAP as database, the username is not case sensitive.
Other apps I used do not have a problem with this. But AirTrail sees it as new user.

Which creates a new user with username and display name being the login with none of my data

Operating System that is running AirTrail

Ubuntu docker

AirTrail Version

3.8.0

Your docker-compose.yml content

services:
  db:
    container_name: airtrail_db
    image: postgres:16-alpine
    restart: always
    env_file:
      - .env
    environment:
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ./db_data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U ${DB_USERNAME} -d ${DB_DATABASE_NAME}']
      interval: 5s
      timeout: 5s
      retries: 5
  airtrail:
    container_name: airtrail
    image: johly/airtrail:latest
    restart: always
    env_file:
      - .env
    ports:
      - 3000:3000
    volumes:
      # Required for file uploads (e.g., airline icons)
      # The path to the right of the colon needs to match UPLOAD_LOCATION in your .env file
      # It needs to be writable for UID:GID 1000:1000
      - ./uploads:/app/uploads
      # If docker isn't running as UID 1000 on your host, consider using a bind mount volume instead, such as:
      # - ./data/uploads:/app/uploads
      # and create the folder ./data/uploads with UID:GID 1000:1000
    depends_on:
      db:
        condition: service_healthy

Your .env content

Reproduction steps

1. set up tinyauth instance connected to LLDAP (users: user1)
2. login to airtrail via tinyauth as user1 and use the new account
3. logout
4. login as user1, everything is as it should
5. logout
6. login as User1 (the same thing in tinyauth)
7. Airtrail creates a new user with name and display name User1
   ...

Relevant log output

Additional information

[johanohly]

Thanks for the report. I dug into this a bit and AirTrail links OAuth users by the OIDC sub claim, not by preferred_username.

That means username casing by itself should not create a duplicate user. A duplicate can only be created here if the identity AirTrail receives from the provider changes as well, which suggests the sub value coming back from tinyauth/LLDAP may not be stable between user1 and User1.

For security reasons, AirTrail should not automatically re-link an already linked account to a different sub, since that could allow account takeover if two identities collide on the same username.

If you're able to check what claims tinyauth returns in both cases, especially sub and preferred_username. that would help confirm it. If sub differs only by case, this likely needs to be fixed in the IdP / OIDC bridge configuration rather than in AirTrail.